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I.  INTRODUCTION 

A.      MOTIVATION 

The  popularity  of  Object-Oriented  Programming  (OOP)  is  steadily  increasing.  As 
more  and  more  people  develop  an  interest  in  the  additional  capabilities  that  arise  from  using 
the  object-oriented  paradigm,  they  realize  the  flexibility  and  power  that  OOP  provides  for 
representing  real  world  objects  in  an  intuitive  and  natural  manner.  This  flexibility  and  high 
level  of  abstraction  provided  by  OOP  constructs  has  lead  many  database  professionals  to 
consider  object-oriented  concepts  as  they  relate  to  database  management  systems  (DBMS). 

During  the  last  decade,  the  business  sector  has  become  increasingly  reliant  upon 
information.  Information  management  and  control  pays  dividends  to  businesses  in  terms  of 
increased  power  and  revenue.  In  the  coming  decade,  this  reliance  will  surely  increase.  The 
requirement  to  manage  very  large  quantities  of  data  more  efficiently  and  to  perform  queries 
on  them  rapidly  is  only  part  of  the  problem.  The  data  that  businesses  wish  to  store  and 
manage  is  becoming  increasingly  complex. 

Some  specific  areas  that  have  an  immediate  need  for  a  database  to  store  and  manage 
complex  data  are  computer  aided  design  (CAD),  computer  aided  software  engineering 
(CASE),  computer-integrated  manufacturing  (CIM),  and  computer  aided  engineering.  Data 
representing  images  and  text  is  applicable  to  virtually  all  large  businesses.  In  the  medical 
field,  for  example,  a  patient's  medical  file  could  be  managed  by  a  database  that  keeps  track 
of  not  only  the  textual  records  from  an  appointment,  but  also  x-rays,  lab  results,  cat  scan 
pictures,  and  other  non-textual  information.  [Me90] 

The  relational  data  model  has  existed  for  many  years.  It  was  developed  by  Codd  in 
1970  [Co70].  This  model  quickly  gained  widespread  acceptance  and  use  commercially. 


Much  of  the  business  sector  has  a  heavy  investment  in  relational  databases,  and  the 
relational  model  is  credible  and  familiar.  Therefore,  there  is  a  reluctance  to  change  to 
another  model/system,  even  when  there  is  a  need. 

Vendors  have  realized  the  need  for  modeling  complex  information  (visual,  textual, 
audible,  etc.).  In  response,  several  object-oriented  databases  management  systems 
(OODBMS)  are  now  available  in  the  commercial  market.  Some  businesses  with  a  need  for 
managing  complex  data  are  using  them.  Many  of  these  businesses  have  expressed  a  desire 
for  an  interface  that  can  access  both  object-oriented  databases  and  relational  databases 
[St91a]. 

B.      OBJECTIVES  OF  A  RELATIONAL/OBJECT-ORIENTED  DATABASE 
SYSTEM 

In  general,  conventional  database  models  are  designed  to  meet  the  requirements  of  a 
specific  need.  As  Hsiao  states,  "this  is  the  notion  of  application  specificity,  i.e.,  being 
specific  to  a  kind  of  database  application."[Hs91,  p.  3]  The  general  areas  that  the 
conventional  data  models,  relational,  hierarchical,  network,  and  functional  data  models,  are 
used  for  are  record  keeping,  product  assemblies,  inventory  controls,  and  inference  making, 
respectively .  [Hs9 1  ] 

The  main  objective  of  this  research  is  to  determine  if  a  single  DBMS  can  be  realized 
that  would  serve  the  needs  of  both  relational  and  object-oriented  users.  A  relational  DBMS 
(RDBMS)  has  many  advantages  over  non-relational  systems.  There  are,  however,  some 
constraints  on  relations,  such  as  the  type  of  real  world  entities  that  it  can  represent. 

An  OODBMS  has  a  more  robust  capability  for  representing  real  world  entities  as 
objects.  The  restriction  on  types  of  relations  in  a  RDBMS  can  be  lifted  in  an  OODBMS. 
Both  RDBMSs  and  OODBMSs  have  their  own  set  of  advantages,  but  they  are  not  the  same 
set  of  advantages.  It  is  desirable  to  have  a  DBMS  that  has  the  advantages  found  in  both  of 


these  sets,  plus  any  additional  advantages  that  may  arise  from  having  a  combined  relational/ 
object-oriented  database  management  system  (R/OODBMS). 

The  user  of  a  R/OODBMS  should  be  able  to  implement  a  relational  schema  and  query 
the  database  using  either  'standard'  relational  queries  or  an  object-oriented  type  query. 
Thus,  there  would  be  a  very  low  learning  curve  for  users  already  accustomed  to  relational 
systems.  Additionally,  they  would  not  have  to  abandon  the  relational  approach  that  they  are 
already  familiar  with  for  this  new  object-oriented  paradigm.  Yet,  they  would  also  gain  the 
capability  to  manage  complex  data/objects  with  the  same  system. 

A  secondary  objective  is  to  determine  if  any  OODBMS  can  be  the  basis  for  a  R/ 
OODBMS.  That  is,  are  there  certain  requirements  that  must  be  met  by  a  commercial 
OODBMS  so  that  a  R/OODBMS  can  be  successfully  constructed?  Also,  are  there  any 
characteristics  of  these  systems  that  would  facilitate  this  construction  more  than  others? 

C.     RESEARCH  OVERVIEW 

This  is  a  feasibility  study  which  continues  previous  work  done  in  the  area  by  Nelson 
[Ne881  and  Filippi  [Fi92].  Implementing  relational  operations  in  IDB  is  the  primary  thrust 
of  this  research.  Additionally,  assessing  the  capabilities  and  advantages  of  using  both 
RDBMSs  and  OODBMSs  falls  within  the  scope  of  this  research.  A  comparison  of  these 
assessments  with  that  of  a  single  R/OODBMS  will  follow  so  that  it  can  be  determined 
whether  the  needs  of  a  RDBMS  and  an  OODBMS  can  be  satisfied  by  a  single  R/OODBMS. 


II.  SURVEY  OF  THE  LITURATURE 

A.  GENERAL 

The  focus  of  this  chapter  is  the  fundamental  terms  and  concepts  in  the  areas  of  object- 
oriented  programming  (OOP),  relational  database  management  systems  (RDBMS),  and 
object-oriented  database  management  systems  (OODBMS).  The  discussion  of  these  topics 
is  not  intended  to  be  a  complete  work  on  them,  but  rather  an  introduction  to  present  those 
concepts  and  terms  necessary  as  a  foundation  for  this  thesis. 

B.  OBJECT-ORIENTED  PROGRAMMING  CONCEPTS 

"I  have  a  cat  named  Trash.  In  the  current  political  climate,  it  would  seem  that  if  I  were 
trying  to  sell  him  (at  least  to  a  Computer  Scientist),  I  would  not  stress  that  he  is  gentle  to 
humans  and  is  self-sufficient,  living  mostly  on  field  mice.  Rather,  I  would  argue  that  he  is 
object-oriented"  [Kin89,  p.  23]. 

What  does  it  mean  for  something  to  be  object-oriented?  Since  the  advent  of  Simula- 
67  in  the  1960s  and  later  Smalltalk  in  the  1970s  [Mi88][Mo89],  object-oriented 
programming  languages  (OOPLs)  and  the  object-oriented  paradigm  have  been  increasingly 
great  topics  for  discussion  and  debate.  Different  products  are  advertised  as  object-oriented, 
the  hot  buzzword,  however  there  is  no  universally  accepted  definition 
[Kin89][Ne91][Ne90b][SB86]. 

"What  is  needed  is  a  definition  general  enough  to  encompass  all  of  the  current  views 
of  OOP,  yet  strong  enough  to  stand  up  as  the  basis  for  the  underlying  theory  of  OOP" 
[Ne91,  p.  4].  The  broad  definition  used  in  this  paper  is  object-oriented  =  objects  +  classes 

+  inheritance  +  encapsulation.  This  is  a  slight  modification  of  the  definition  in  [We87]. 


Currently,  there  is  also  much  debate  about  the  design  process  for  an  OOP  program. 
In  conventional  languages,  several  approaches  have  been  formalized  such  as  the  top-down, 
bottom-up,  structured,  etc.  These  approaches  are,  in  general,  'action'  approaches  while 
OOP  uses  an  'object'  approach  [GH91b].  However,  the  OOP  community  lacks  any 
established  methodology  to  their  'object'  approach  [PN91b].  This  subject  is  considered  to 
be  beyond  the  scope  of  this  paper,  however,  and  as  such  will  not  be  discussed  any  further. 

1.     Classes/Objects 

A  class  may  be  defined  as  "a  description  of  one  or  more  similar  objects"  [SB86, 
p.  43].  An  object  is  an  instantiation  of  a  class  [Mo89].  Clearly,  this  is  a  circular  definition 
which  can  be  avoided  by  defining  an  object  as  the  fundamental  element  of  OOP.  That  is, 
an  object  is  a  self-contained  set  of  variables  (which  may  be  thought  of  as  attributes  in 
database  terms),  and  responds  only  to  messages  to  execute  specific  defined  procedures 
(also  called  methods  in  OOP  terms)  [BM91][Ne91][SB86].  An  object's  method(s)  are  the 

only  means  by  which  manipulation  of  its  variables  can  occur. 

The  description  of  an  object/class  is  composed  of  variables/attributes  and  the 
procedures/methods  that  operate  on  them.  These  variables  and  methods  describe  general 
characteristics  that  all  instances  of  a  class  have.  The  only  way  to  communicate  with  an 
object  is  through  messages  to  execute  its  methods.  Thus,  an  object's  messages  are  the 
interface  to  a  particular  object.  An  important  point  is  that  the  variables  of  an  object  may 


1.  [We87]  defines  OOP  as  "object-oriented  =  objects  +  classes  +  inheritance".  It  may  be  argued  that 
this  equation  is  the  same  as  our  slightly  modified  equation  since  some  definitions  of  class  imply  en- 
capsulation. For  a  more  detailed  discussion,  see  [Ne91] 

2.  Thus,  a  class  may  be  thought  of  as  an  abstract  data  type  (ADT)  or  as  the  implementation  of  an 
ADT  [Da84][Ne91].  The  interface  to  the  data  type  is  defined  solely  by  the  methods  defined  for  the 
class.  The  implementation  of  these  methods  is  contained  within  the  class  which  allows  the  interface 
to  be  implementation-independent. 


themselves  be  objects.  In  this  case,  the  object  is  called  a  composite  object  that  has  at  least 
one  variable  which  is  a  previously  defined  object  [EN89][Ne90b].  The  composition  of 
composite  objects  can  be  compared  with  inheritance  where  composition  is  a  form  of  part 
inheritance  the  later  is  concerned  more  with  behavior  inheritance  [Ne90b]. 

Most  OOP  languages  provide  for  both  class  and  instance  variables,  although  it  is 
not  required  for  a  language  to  be  considered  object-oriented  [Ne91][Ne90b].  The 
difference  is  that  a  class  variable  will  have  the  same  value  for  all  instances  of  the  class.  If 
a  method  in  any  of  the  instances  of  that  class  change  the  value  of  a  class  variable,  then  the 
value  is  changed  for  every  instance  of  the  class.  Thus,  it  is  a  variable  shared  by  all  instances 
of  the  class.  In  contrast,  an  instance  variable  has  a  local  value  for  a  particular  instance.  A 
change  to  the  value  of  an  instances  instance  variable  of  one  object  has  no  effect  on  the 

corresponding  variable  in  another  instance  of  the  class. 

Consider  a  military  officer  as  an  example  of  an  entity  that  might  be  described  in 
a  class  definition.  The  class  name  could  be  Officer  with  several  variables  that  further 
characterize  an  officer.  A  possible  class  variable  could  be  the  number  of  company  grade 
officers  (0-1  through  0-3)  that  exist:  CompanyGradeCount.  Thus,  every  instance  of  the 
Officer  class  would  have  the  same  value  for  CompanyGradeCount.  Each  officer  has  a 
name,  grade,  social  security  number,  and  an  assigned  unit  that  may  be  represented  by  the 
instance  variables  Name,  Grade,  SSN,  and  Unit,  respectively.  These  variables  would  be 
instance  variables  since  each  instance  of  an  officer  will  not  necessarily  have  the  same 
values  for  each  of  these  variables.  This  officer  class  definition  is  presented  in  Figure  1. 


3.  IDB,  the  OODBMS  used  in  this  thesis,  does  not  provide  the  capability  to  define  class  variables. 
However,  in  our  discussions  with  Persistent  Data  Systems,  they  have  mentioned  that  later  versions 
of  IDB  may  contain  this  capability. 


Class:  Officer 

Superclass: 

none 

Class  Variables: 

CompanyGradeCount 

Instance  Variables: 

Name,  Grade,  SSN,  Unit 

Methods: 

Promote,  Retire,  Relocate 

Figure  1  Class  Definition  Example 

2.     Methods 

As  previously  mentioned,  methods  are  the  means  by  which  an  objects  variables 
are  manipulated  [Ne90b].  They  define  the  only  legal  actions/operations  that  characterize  an 
object.  A  method  is  invoked  by  sending  an  object  a  message  to  invoke  one  of  its  methods. 

A  message  can  be  likened  to  a  procedure  call  in  a  conventional  programming  language. 
Changing  the  implementation  details  for  any  method  should  have  no  effect  on  messages 
needed  to  invoke  that  method  [Ne90b].  Thus,  code  that  uses  message  passing  for  method 
invocation  is  implementation  independent.  It  is  in  this  sense  that  the  description/definition 
of  class  may  imply  encapsulation  (also  called  information  hiding). 

In  our  military  officer  example,  it  may  be  desirable  to  be  able  to  promote,  retire, 
or  relocate  an  officer.  Therefore,  these  three  actions  might  be  implemented  as  methods  for 
the  Officer  class  (see  Figure  1).  The  Promote  method  would  change  the  Grade  instance 
variable  and  could  change  the  CompanyGradeCount  class  variable;  Relocate  would  change 


4.  The  exact  implementation  for  the  message  passing  concept  may  vary  among  different  OOP  lan- 
guages.Value  operations  (idl_vop)  and  type  operations  (idl_top)  are  the  means  by  which  IDB  imple- 
ments message  passing. 


the  Unit  instance  variable;  and  Retire  would  change  the  Unit  and  Grade  instance  variables, 
and  possibly  the  CompanyGradeCount  class  variable. 

3.     Inheritance 

Inheritance  allows  further  specialization  of  a  class  (called  the  superclass)  by 
exploiting  class  similarities  [Ni89].  That  is,  a  subclass  inherits  the  variables  and  methods 

of  its  ancestors  and  adds  its  own  variables  and  methods.  In  this  way,  it  is  a  specialization 
of  its  ancestors  and  its  ancestors  are  a  generalization  of  the  subclass 
[BM91][CY90][HO87][Hs91][Mi88][Mo89].  In  more  fundamental  terms,  it  is  a  form  of 
code  sharing  [Ne90b]  that  facilitates  and  encourages  code  reuse  [Ni89][Mi88].  As  you 

travel  down  an  inheritance  hierarchy  ,  classes  become  more  specialized.  As  you  travel  up, 
they  become  more  generalized. 

In  Figure  2,  the  class  Human  is  the  superclass  of  the  subclass  ServiceMember.  A 
simple  inheritance  hierarchy  of  these  two  classes  is  shown  in  Figure  3.  Any  ServiceMember 
will  have  Species  as  a  class  variable;  Weight,  Height,  Sex,  and  Ssn  as  instance  variables; 
and  the  methods  Bom,  Die,  EnterService,  and  DepartService.  A  ServiceMember  is  a 
specialization  of  a  Human,  while  a  Human  is  a  generalization  of  a  ServiceMember. 


5.  Inheritance  of  methods  is  sometimes  called  behavioral  inheritance  while  inheritance  of  variables 
is  called  structural  inheritance  [Da90]. 

6.  An  inheritance  hierarchy  is  simply  a  graphical  representation  of  the  inheritance  relationship  be- 
tween classes  [Ne90b). 


Class: 

Human 

Superclass: 

none 

Class  Variables: 

Species 

Instance  Variables: 

Weight,  Height,  Sex 

Methods: 

Born,  Die 

Class: 

ServiceMember 

Superclass: 

Human 

Class  Variables: 

none 

Instance  Variables: 

Ssn 

Methods: 

EnterService,  DepartService 

Figure  2  A  Class  and  Its  Subclass 


Human 


ServiceMember 


Figure  3  A  Simple  Inheritance  Hierarchy 

Consider  the  inheritance  hierarchy  in  Figure  4,  Officer  is  now  a  subclass  of 
ServiceMember.  The  ancestors  of  Officer  are  Human  and  ServiceMember,  while  its 
descendents  are  the  subclasses  CompanyGrade,  FieldGrade,  and  FlagGrade.  Thus,  the  class 
Officer  inherits  all  the  variables  and  methods  from  both  Human  and  ServiceMember. 
Again,  you  can  see  that  as  you  travel  down  the  inheritance  hierarchy  the  classes  become 
more  specialized  while  the  classes  higher  in  the  hierarchy  are  more  general. 


7.  The  Officer  class  definition  in  Figure  1  would  have  to  be  modified  to  reflect  that  ServiceMember 
is  now  its  superclass. 


Human 


ServiceMember 


Enlisted 


Officer 


Company 
Grade 


Field 
Grade 


Flag 
Grade 


Figure  4  A  More  Complex  Inheritance  Hierarchy 

Methods  that  are  inherited  by  a  class  may  have  their  implementation  overridden 
(or  redefined)  while  still  maintaining  the  same  method  name  [H087][Mi88].  This  allows 
methods  to  be  overloaded  (also  called  polymorphism)  [Ne90b][Ni89][SB86].  That  is,  the 
same  message  may  be  sent  to  different  objects,  invoking  different  implementations  of  the 
same  method  depending  on  the  object  which  receives  the  message.  A  common  example  of 
polymorphism  is  that  of  the  binary  arithmetic  operations  on  integers  and  real  numbers. 
When  we  want  to  add  two  integers,  we  write  2+39;  the  same  operator  name  '+'  is  also  used 
for  the  real  numbers,  3.4+2.1. 

In  the  example  hierarchy  (Figure  4),  the  subclasses  of  Officer  all  inherit  the 
method  Promote  (along  with  the  other  methods  of  the  Officer  class).  However,  each  of  the 
subclasses  (except  for  CompanyGrade)  require  a  different  implementation  for  the  Promote 
method  since  promoting  a  FlagGrade  or  FieldGrade  officer  would  not  change  the  Officer 

Q 

class  variable  CompanyGradeCount.   A  method  that  has  been  overwritten  by  a  subclass  is 
a  polymorphic  method. 
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Up  to  this  point,  our  discussion  of  inheritance  has  focused  only  on  single 

inheritance:  a  class  inherits  from  only  one  superclass.  However,  some  languages  allow  for 
multiple  inheritance:  a  class  inherits  from  two  or  more  superclasses  [Ne91][Ne90b].  The 
relationship   between  classes   when  multiple   inheritance   is  allowed  can   be   shown 

graphically  in  a  multiple  inheritance  lattice     (see  Figure  5)  [SB86][Ne90b]. 


Human 


ServiceMember 


Student 


Enlisted 


Officer 


Nps 
Student 


Figure  5  A  Multiple  Inheritance  Lattice 

Inheritance  is  not  without  its  own  special  problem  which  must  be  mentioned;  that 
of  name  conflicts  [Ki91][Mi88][Ne88][NMO90].  In  Figure  5,  assume  that  the  Human  class 


8.  This  assumes  that  in  the  Officer  class  definition  the  Promote  method  has  the  implementation  pre- 
viously described:  Promote  changes  the  value  of  the  CompanyGradeCount  class  variable.  Thus,  if 
the  method's  implementation  is  not  overwritten  a  message  sent  to  any  of  Officer's  subclasses  would 
invoke  this  implementation  causing  undesirable  results. 

9.  Generally,  the  term  inheritance  by  itself  means  only  single  inheritance  [Ne90b]. 

10.  The  term  lattice  by  definition  allows  more  than  one  superclass  [SB86]  while  an  inheritance  hi- 
erarchy does  not.  This  is  in  contrast  to  a  hierarchy  which  is  represented  as  a  tree.  However,  it  is  fairly 
common  practice  to  refer  to  a  multiple  inheritance  lattice  more  simple  as  a  multiple  inheritance  hi- 
erarchy [Ne90b]. 
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has  a  Print  method  that  has  been  overridden  in  both  the  Officer  and  Student  subclasses. 
Now,  consider  the  class  NpsStudent;  which  implementation  of  Print  does  it  inherit? 

In  the  case  of  single  inheritance,  a  subclass  may  inherit  a  method  X  or  variable  Y 
from  its  ancestors  but  also  have  a  different  method  X  or  variable  Y  defined  locally  for  the 
subclass  [Ni89][NMO90].  That  is,  the  subclass  also  has  in  its  class  definition  a  method  X 
and  a  variable  Y.  How  are  the  two  different  methods  or  variables  differentiated?  Usually 
locally  defined  methods  and  variables  override  any  inherited  methods  and  variables  with 
the  same  name.  However,  some  systems  allow  the  overridden  method/variable  in  the 
superclass  to  be  accessed  by  prefacing  the  name  with  super;  for  example,  superX  or  superY. 

Multiple  inheritance  has  a  similar  name  problem,  however  it  is  complicated  since 
there  is  more  than  one  superclass  involved.  It  is  not  as  simple  to  just  preface  a  redefined 
name  with  super  since  more  than  one  of  the  superclasses  may  have  the  same  method/ 
variable  name.  In  general,  the  possible  solutions  include  making  a  choice  between  them 
using  some  default  criteria  [SB86]  (such  as  a  class  precedence  [Mo89][SB86]),  by 
distinguishing  among  them  [Ne88]  (possibly  by  using  their  parent  class  name  as  a  prefix 
[Ni89]),  by  combining  them  [Mo89][Ne88],  or  by  requiring  the  programmer  to  make  an 
explicit  choice  [Ki91][Mi88][Ni89]. 

4.     Encapsulation 

"An  OOPL  supports  encapsulation  if  it  allows  users  of  objects  to  access  them  only 
via  their  external  interfaces"  [Mi88,  p.  15].  The  external  (public)  interfaces  to  an  object  are 
its  methods  and  these  are  the  only  means  that  a  user  has  for  accessing/manipulating  an 
object.  The  user  is  not  allowed  direct  access  to  the  object  and  its  inner  workings[Da90]. 
Thus,  encapsulation  is  a  method  of  information  hiding  [Da90][Ne90b][Ne91]  and  offers 
protection  to  objects  from  unauthorized/illegal  operations  on  its  variables  [Mo89]. 
Additionally,  hiding  implementation  details  provides  a  separation  (or  decoupling)  from  the 
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code  that  defines  and  implements  an  object  from  that  of  the  program  code  using  the  object 
[Da90].  This  point  is  quite  important  since  it  allows  changes  to  an  object's  implementation 
without  having  to  change  the  user's  program  code  and  vice-verse  [Da90][Mo89][Ne91]. 

C.      RELATIONAL  DATABASE  MANAGEMENT  SYSTEMS 

Prior  to  discussing  the  relational  model  specifically,  it  is  worth  giving  a  few  moments 
to  the  definition  of  a  database  management  system  (DBMS).  A  DBMS  is  a  collection  of 
general-purpose  software  programs  that  allow  maintenance  of  and  access  to  a  collection  of 
interrelated  data  [EN89][KS86].  A  collection  of  interrelated  data  is  called  a  database. 

However,  when  discussed  in  terms  of  specific  DBMSs,  the  definition  of  database  is  a 
little  more  restrictive  and  has  the  following  properties[EN89]: 

•  the  collection  of  data  has  some  inherit  meaning  and  is  logically  coherent; 

•  the  database  is  created  for  a  specific  purpose,  an  intended  group  of  users,  and 
some  preconceived  applications;  and 

•  the  database  models  and  reflects  some  real  world  aspect. 

The  maintenance  of  and  access  to  the  data  include  facilities  to  define,  create,  and 
manipulate  (i.e.,  query  and  update)  it. 

There  are  numerous  considerations  for  using  a  DBMS.  Controlling  redundancy:  as  the 
number  of  times  the  same  data  is  stored  increases,  there  is  a  corresponding  increase  in 
duplication  of  effort  to  update  it;  additionally,  it  is  more  likely  that  inconsistencies  among 
the  data  may  arise  (update  anomalies).  Sharing  of  data:  in  a  multiuser  DBMS  concurrency 
control  of  updates  is  critical  to  the  correctness  of  updates.  Restricting  unauthorized  access: 
the  DBMS  should  allow  restrictions  to  be  placed  on  access  to  database  data.  Representing 
complex  relationships  among  data:  this  includes  easy  and  efficient  retrieval  and  update  of 
related  data.  Enforcing  integrity  constraints:  database  designers  must  be  allowed  to  specify 
data  constraints  which  the  DBMS  can  enforce  automatically  or  which  can  be  enforced  by 
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update  programs.  Provide  backup  and  recovery:  recovery  from  hardware  and  software 
failures  is  the  DBMS's  responsibility.  [EN89][KS86] 

1.     Relational  Model  Concepts 

In  1968,  Dr.  Edgar  F.  Codd  had  the  idea  that  "predicate  logic  could  be  applied  to 
maintaining  the  logical  integrity  of  the  data"  in  a  DBMS  [CD90,  p.  35].  This  was  the 
conception  of  the  relational  data  model.  Two  years  later,  Codd  introduced  his  model  in  a 
paper  published  in  the  Communications  of  the  ACM  [Co70].  It  was  a  departure  from  what 
had  until  that  time  been  the  conventional  models  (hierarchical  data  model  and  the  network 
data  model)  since  his  model  allowed  for  a  more  abstract  representation  of  the  database 
[OV91][KS86][Fi92].  This  simplistic  yet  complete  model  has  evolved  into  a  kind  of 
defacto  standard  in  the  database  industry. 

The  relational  model  is  firmly  founded  in  strong  mathematical  concepts  and 
theory.  Predicate  logic  and  set  theory  are  the  primary  foundation  upon  which  the  relational 
model  rests.  This  allows  a  formalism  in  the  way  that  data  is  represented  and  manipulated 
in  the  context  of  the  model. 

a.    Relations 

The  relational  model  represents  a  database  as  a  collection  of  relations. 
Relations,  the  fundamental  building  block  of  the  model,  are  represented  by  the  intuitive 
notion  of  a  table  (or  flat  file)  of  values  [Da84][EN89][KS86][OV91][SSU91].  Each  row  of 
the  table  represents  a  tuple  of  the  relation.  A  tuple  is  a  collection  of  data  values  that  are 
related.  The  columns  of  the  table  represent  attributes  of  the  relation  (see  Figure  6).  In  the 
sample  relational  database,  there  are  two  relations:  Officer  and  Military  Unit.  Each  tuple  is 
interpreted  as  a  fact  that  describes  a  relation  instance.  Every  attribute  value  within  a  tuple 

must  be  atomic.  That  is,  it  is  not  constructed  of  other  components;  it  is  indivisible. 
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Officer 

Name 

SSN 

Unit 

Spear 

550-34-2453 

3BDE 

Walter 

233-45-3423 

2BDE 

Nash 

241-4500974 

1BDE 

Rothlisberger 

123-45-6789 

3BDE 

MilitaryUnit 

UnitName 

Location 

CdrSSN 

1BDE 

Grafenwohr 

123-45-6789 

2BDE 

Erlangen 

550-34-2453 

3BDE 

Bamberg 

233-45-3423 

Figure  6  Sample  Relational  Database 

However,  it  must  be  understood  that  there  is  a  subtle  but  important  difference 
between  a  relation  and  a  table.  A  relation  is  a  set  of  tuples.  On  the  other  hand,  tuples  of  a 
relation  are  represented  as  the  rows  of  a  table.  A  set  by  definition  is  unordered,  but  clearly 
the  rows  of  a  table  are  ordered  (from  top  to  bottom)[EN89].  Thus,  the  relation  Officer  in 
Figure  7  is  the  same  as  the  Officer  relation  in  Figure  6. 


11.  This  requirement  for  atomic  attributes  is  called  the  first  normal  form.  Normalization  is  a  process 
of  decomposing  relational  schemas  into  smaller  relations  that  conform  to  several  criteria:  first,  sec- 
ond, and  third  normal  forms.  The  goal  of  normalization  is  to  aid  database  designers  in  analyzing  a 
database  schema  and  developing  a  database  with  a  'good'  design  that  avoids  update  anomalies. 

[EN89] 
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By  the  same  token,  the  order  of  the  columns  is  not  important  since  a  tuple  can 
be  thought  of  as  a  set  of  (<attribute>,<value>)  pairs[EN89][Da84].  The  value  in  each  pah- 
must  fall  within  the  domain  of  its  associated  attribute.  Thus,  the  first  tuple  in  Figure  7  could 
be  written:  (Name,Rothlisberger),  (SSN,  123-45-6789),  (Unit,3BDE);  or  (Unit,3BDE), 
(Name,Rothlisberger),  (SSN,  123-45-6789);  etc. 


Officer 

Name 

SSN 

Unit 

Rothlisberger 

123-45-6789 

3BDE 

Nash 

241-4500974 

1BDE 

Spear 

550-34-2453 

3BDE 

Walter 

233-45-3423 

2BDE 

Figure  7  Reordered  Officer  Relation 

The  reason  this  subtle  difference  between  relations  and  tables  is  important 
will  become  more  apparent  later.  As  will  be  discussed,  all  of  the  relational  algebra  operators 
take  relations  as  parameters  and  yield  results  that  are  also  relations  [Da84].  Thus,  they  are 
set  operations  and  they  have  firm  foundations  in  mathematical  set  theory.  Consequently,  if 
someone  has  a  good  understanding  of  mathematical  set  theory,  then  they  are  well  on  their 
way  to  understanding  relational  algebra. 

Another  consequence  of  a  relation  being  defined  as  a  set  of  tuples,  is  that,  by 
definition,  each  element  in  a  set  is  unique.  Therefore,  all  tuples  in  a  relation  must  be  unique. 
This  implies  that  there  are  no  two  tuples  in  a  relation  that  have  the  same  combination  of 
values  for  all  attributes  [EN89].  Thus,  there  is  some  combination  of  attributes  that  allows 
each  tuple  of  a  relation  to  be  uniquely  identified;  this  combination  is  called  a  primary  key 
(the  primary  key  of  each  relation  in  Figure  6  and  Figure  7  is  underlined).  In  the  worst  case, 
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the  primary  key  is  the  set  of  all  attributes  of  the  relation  [Da84][EN89].  A  detailed 
discussion  of  keys  (including  superkeys,  minimal  superkeys,  candidate  keys,  primary  keys, 
and  foreign  keys)  can  be  found  in  [EN89]. 

b.    Schemas  and  Constraints 

When  discussing  databases,  it  is  important  to  differentiate  between  the 
database  schema  and  database  instance.  A  database  schema  is  a  set  of  relation  schemas  and 
a  set  of  integrity  constraints  while  an  instance  is  a  snap-shot  of  the  data  in  the  database  at 
a  given  instant  in  time[KS86][EN89].  A  relational  schema  can  be  thought  of  as  a  template 
for  the  relation.  The  type  definition  in  programming  language  notation  bears  a  close 
correspondence  to  a  relation  schema  [KS86].  The  schema  is  known,  in  database  terms,  as 
intention  of  the  relation  while  the  instance  is  the  extension  [EN89]. 

In  the  previous  examples  (Figure  6  and  Figure  7),  the  Officer  relation  and  the 
Military  Unit  relation  are  both  examples  of  a  relation  instance.  Figure  8  shows  the  relational 
schemas  for  the  Officer  and  Military  Unit  relations.  Another  notation  for  a  schema  is  a 
listing  of  the  relation's  attributes  and  their  corresponding  domains[KS86]: 

•  Officer-scheme  =  (Name  :  string,  SSN  :  integer,  Unit :  string) 

•  Military  Unit-scheme  =  (UnitName  :  string,  Location  :  string,  CdrSsn  :  integer) 


Officer 

Name 

SSN 

Unit 

MilitaryUnit 

UnitName 

Location 

CdrSSN 

Figure  8  Sample  Relational  Database  Schema 
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In  general,  integrity  constraints  are  defined  for  a  database  schema  and  should 
hold  for  every  instance  of  the  schema  [EN89].  There  are  several  types  of  integrity 
constraints:  key  constraints,  entity  integrity  constraints,  and  referential  integrity  constraints 
[Da84][EN89][OV91].  Key  constraints  are  concerned  with  ensuring  the  uniqueness  of  key 
values  for  every  tuple  in  any  relation  instance  of  a  schema.  Entity  integrity  constraints 
restrict  primary  key  values  to  be  non-null  [OV91].  Finally,  referential  integrity  constraints 
maintain  consistency  between  tuples  of  two  relations  [OV91].  That  is,  if  a  tuple  in  one 
relation  refers  to  another  relation,  then  it  must  refer  to  a  tuple  that  exists  in  that  relation.  An 
additional  general  constraint  that  is  sometimes  needed  is  called  a  semantic  integrity 
constraint  [EN89].  In  our  military  example,  a  semantic  integrity  constraint  would  be  that 
'an  officer  in  a  unit  cannot  outrank  the  commander  of  his  unit'. 

c.     Operations 

Three  fundamental  update  operations  exist  for  relations:  modify,  delete,  and 
insert.  Delete  and  insert  do  what  is  expected  -  insert  and  delete  tuples,  respectively.  Modify 
allows  values  of  some  or  all  attributes  of  a  tuple  to  be  changed.  The  most  important  aspect 
in  performing  these  operations  is  to  ensure  that  the  integrity  constraints  defined  for  the 
schema  are  not  violated.  Therefore,  if  any  integrity  constraints  would  be  violated  by  the 
update  operation,  then  either  the  operation  can  be  rejected  or  the  system  may  attempt  to 
correct  the  reason  that  the  operation  violates  integrity  constraints.  [EN89] 

It  is  possible  for  an  insert  operation  to  violate  all  three  of  the  integrity 
constraints:  key  constraints,  entity  integrity  constraints,  and  referential  integrity 
constraints.  However,  the  delete  operation  can  only  violate  the  referential  integrity 
constraint.  Both  key  constraints  and  referential  integrity  constraints  can  possibly  be 
violated  by  a  modify  operation.  [EN891 


18 


2.     Formal  Query  Languages 

Along  with  Codd's  initial  presentation  of  the  relational  model  in  1970,  he  also 
proposed  two  formal  query  languages:  relational  algebra  and  relational  calculus  [Co70]. 
Before  discussing  the  fundamental  differences  in  the  two,  it  should  be  noted  that  it  has  been 
shown  that  they  are  equivalent  in  expressive  power  [EN89][OV91].  Thus,  any  query  that 
can  be  specified  in  one  language  can  also  be  specified  in  the  other.  Query  languages  can 
therefore  be  compared  against  either  of  these  two  to  determine  if  they  are  relationally 
complete  [EN89]. 

Relational  algebra,  in  contrast  to  relational  calculus,  is  more  closely  related  to  the 
underlying  system  instructions  that  perform  the  operations  [KS86].  This  is  the  primary 
reason  that  relational  algebra  was  chosen  over  relational  calculus  for  use  in  this  thesis. 
Since  the  two  are  logically  equivalent,  it  is  sufficient  to  implement  only  one.  Thus,  in  the 
discussion  that  follows,  relational  algebra  will  be  discussed  in  more  detail  than  relational 
calculus. 

The  fundamental  difference  between  the  two  languages  is  that  of  a  procedural 
language  verses  a  nonprocedural  (or  declarative)  language.  In  a  procedural  language,  such 
as  relational  algebra,  the  query  specifies  the  sequences  of  instructions  necessary  to  obtain 
the  result.  This  is  in  contrast  to  nonprocedural  language,  such  as  relational  calculus,  which 
specifies  a  query  by  delineating  what  information  is  desired  rather  than  how  it  is  to  obtain 
the  information  (i.e.,  the  procedure  to  be  followed).  [EN89][KS86] 

a.    Relational  Algebra 

Relational  algebra  is  a  procedural  language.  Therefore,  it  more  directly 
corresponds  to  the  operations  necessary  to  satisfy  a  query.  The  set  of  operations  that 
constitute  relational  algebra  are  derived  from  the  mathematical  theory  of  sets  [OV91].  Each 
operation  has  as  its  parameter(s)  a  relation  and  returns  a  result  that  is  also  a  relation  [Da84]. 
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Codd  proposed  eight  operations  in  his  presentation  of  the  relational  model  in  1970:  union, 
intersection,  difference,  Cartesian  product,  select,  project,  join,  and  divide  [Da84]. 
However,  it  can  be  shown  that  of  the  eight  only  five  are  primitive  operations:  select,  project, 
union,  difference,  and  Cartesian  product  [Da84][EN89][KS86][NMO90].  The  other  three 
non-primitive  operations  can  be  formed  by  some  combination  of  the  five  primitive  ones. 

(1)  Select  is  a  unary  operation,  taking  a  relation  as  its  parameter  and 
yielding  a  subset  of  tuples  from  that  relation  as  its  result.  The  resultant  relation  has  the  same 
relational  schema  as  the  input  parameter  relation.  To  identify  the  tuples  that  are  to  be  in  the 
resultant  relation,  a  selection  condition  (predicate)  is  specified  in  the  select  expression  on 
the  specified  relation.  All  tuples  in  the  resultant  relation  will  satisfy  the  selection  condition. 
[EN89][KS86] 

The  selection  condition  is  a  boolean  expression  consisting  of  clauses  of 
the  form: 

<name  of  attributexcomparison  operatorxconstant  value>; 

or 
<name  of  attributexcomparison  operatorxname  of  attributo 

where  <name  of  attributo  is  the  name  of  an  attribute  of  the  input  parameter  relation; 
<comparison  operator>  is  either  =,  <,  <,  >,  >,  or  =£;  and  <constant  value>  is  any  arbitrary 
number  of  clauses  may  be  connected  with  the  AND,  OR,  and  NOT  operators  to  form  the 
selection  condition  expression  [EN89]. 

In  Figure  9,  ResultRelation  is  the  resultant  relation  from  performing  a 
select  operation  on  the  relation  Officer  (Figure  7)  where  Unit  =  3BDE.  The  original  Officer 
relation  had  4  tuples  while  the  resultant  ResultRelation  has  only  2.  The  selection  condition 
can  be  arbitrarily  complex. 
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Result  Relation 

Name 

££N 

Unit 

Rothlisberger 

123-45-6789 

3BDE 

Spear 

550-34-2453 

3BDE 

Figure  9  Example  Result  of  a  Select  Operation 

(2)  Project  is  also  a  unary  operation.  The  project  operation  uses  an  attribute 
list  to  select  the  attributes  that  will  appear  in  the  resultant  relation.  The  attribute  list  must 
be  a  subset  of  the  attributes  of  the  input  parameter  relation.  The  schema  of  the  resultant 
relation  in  this  case  is  not  the  same  as  the  input  parameter  relation.  The  attributes  are  a 
subset  of  the  attributes  in  the  input  parameter  relation.  However,  the  attributes  in  the  result 
will  be  listed  in  the  order  that  the  attributes  are  listed  in  the  attribute  list.  However,  the 
resultant  relation  will  have  the  same  number  of  tuples.  [EN89] 

In  Figure  10,  ResultRelation  is  the  resultant  relation  from  a  projection 
operation  of  the  Name  and  SSN  fields  of  the  Officer  relation  (Figure  7).  The  original 
Officer  relation  has  three  attribute  fields  while  the  resultant  ResultRelation  only  has  two. 
However,  both  relations  have  the  same  number  of  tuples. 
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ResuItRelation 

Name 

SSN 

Rothlisberger 

123-45-6789 

Nash 

241-4500974 

Spear 

550-34-2453 

Walter 

233-45-3423 

Figure  10  Example  Result  of  a  Project  Operation 

(3)  Union,  in  contrast  to  the  first  two  operations,  is  a  binary  operation.  It 
along  with  the  operations  difference  and  Cartesian  product  are  the  standard  mathematical 
set  operations  [Da84][EN89].  Thus,  the  union  of  two  relations  is  a  resultant  relation  that  is 
the  set  of  all  tuples  that  belong  to  either  relation  or  to  both.  This  operation,  along  with  the 
difference  operation,  can  only  be  executed  if  the  two  input  parameter  relations  are  union 
compatible.  That  is,  they  must  have  the  same  number  of  attributes  (the  same  degree)  and 
the  corresponding  attribute  must  be  based  on  the  same  domain  (although  they  need  not  have 
the  same  name)  [Da84].  As  an  example,  two  union  compatible  relations  are  shown  in 
Figure  1 1.  The  resultant  relation  has  the  same  degree  as  the  input  relations.  Note  that  the 
order  of  the  attributes  in  the  relations  is  important  for  checking  union  compatibility. 
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OfficerReserve 


FirstName 

LastName 

Ron 

Spear 

James 

Schledorn 

Leonard 

Tharpe 

EnlistedActive 


Fname 

Lname 

James 

Justice 

John 

Walter 

Luther 

Moen 

Jane 

Pauli 

James 

Schledorn 

ResultRelation 


first_name 

last_name 

Ron 

Spear 

James 

Schledorn 

Leonard 

Tharpe 

James 

Justice 

John 

Walter 

Luther 

Moen 

Jane 

Pauli 

Figure  11  Union  Compatible  Relations  and  Result  of  Union 
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(4)  Difference,  given  two  input  parameter  relations,  A  and  B,  produces  a 
resultant  relation  which  is  comprised  of  all  tuples  in  A  that  are  not  in  B.  As  with  the  union 
operation,  the  input  parameter  relations  A  and  B  must  be  union  compatible.  Therefore,  the 
difference  of  relations  OfficerReserve  and  EnlistedActive  (from  Figure  11)  is  shown  in 
Figure  12.  However,  the  difference  of  EnlistedActive  and  OfficerReserve  would  be  a 
resultant  relation  that  contains  all  of  the  tuples  in  relation  EnlistedActive  except  for  the  last 
tuple  which  contains  James  Schledorn  and  no  tuple  from  OfficerReserve. 


OfficerEnlisted 


first-name 

last-name 

Ron 

Spear 

Leonard 

Tharpe 

Figure  12  Result  of  Difference  Operation  on  Relations  in  Figure  1 1 

(5)  Cartesian  Product,  the  last  of  the  set  operations,  differs  from  the 
previous  two  operations,  union  and  difference,  in  two  main  ways.  First,  if  the  Cartesian 
product  operator  is  operating  on  relations  A  and  B  which  have  2  tuples  with  3  attributes  and 
5  tuples  with  4  attributes  respectively,  then  the  resultant  relation  will  have  10  (2  *  5)  tuples 
and  7  (3  +  4)  attributes.  In  our  previous  example  (Figure  1 1),  the  Cartesian  product  of  the 
two  relations  would  have  a  resultant  relation  with  15  (3  *5)  tuples  and  4  (2  +  2)  attributes. 
Secondly,  the  two  input  parameters  to  this  operation  need  not  be  union  compatible. 

b.    Relational  Calculus 

While  relational  algebra  is  founded  on  the  mathematical  principles  of  set 
theory,  relational  calculus  (a  procedural  language)  is  founded  on  first  order  predicate 
calculus  [EN89].  Two  well-know  forms  comprise  the  relational  calculus:  tuple  relational 
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calculus  and  domain  relational  calculus.  There  is  a  strong  similarity  between  the  two  forms. 
As  their  names  imply,  tuple  relational  calculus  is  the  form  in  which  variables  represent 
tuples  while  domain  relational  calculus  uses  variables  to  represent  attribute  domain  values 
[PCS 86].  In  tuple  relational  calculus,  the  database  is  viewed  as  a  set  of  tuples,  while  in 
domain  relational  calculus  it  is  viewed  as  a  set  of  domains.  Thus,  meaning  is  given  to 
queries  by  interpreting  variables  as  assertions  on  the  database  [OV91]. 

3.     Other  Query  Languages 

SQL,  QUEL,  and  QBE  are  three  commercial  query  languages  that  expand  on  the 
formal  languages  previously  discussed,  relational  algebra  and  relational  calculus.  Both 
SQL  and  QUEL  are  relationally  complete  languages,  however,  some  implementations  of 
QBE  are  not  (they  lack  explicit  universal  and  existential  quantifiers)  [EN8 9].  In  general, 
they  provide  a  higher  level,  more  friendly  user  interface  along  with  other  facilities  for  data 
definition    (a    data    definition    language    function,    DDL),    data    manipulation    (data 

manipulation  language  facilities,  DML),  and  security  constraint  specification  [KS86].  It 
is  considered  beyond  the  scope  of  this  thesis  to  discuss  these  other  areas.  However,  each  of 
these  languages  will  be  reviewed  very  briefly  in  this  section  to  give  the  reader  a  feel  for 
considerations  in  implementing  a  commercial  query  language.  All  of  these  languages  are 
more  declarative  than  procedural. 

a.    SQL 

The  Structured  Query  Language,  SQL,  is  still  referred  to  as  Sequel 
(Structured  English  QUEry  Language)  by  many  people  and  is  probably  the  most  well 
known  of  the  three.  SQL  combines  constructs  from  both  relational  algebra  and  calculus 


12.  Although,  each  language  does  not  necessarily  provide  for  all  of  these  facilities. 
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[EN89][KS86].  It  has  become  somewhat  of  a  defacto  standard  relational  database 
language.  Queries  in  SQL  can  be  interactive  or  embedded  in  an  application  [Da84]. 
The  basic  format  for  a  SQL  query  is: 

S  ELECT        <list  of  attributes> 

FROM  <list  of  tables> 

WHERE  <condition> 
where  <list  of  attributes>  is  a  list  of  names  for  which  values  are  desired  (corresponds  to  the 
relational  algebra  project  operation),  <list  of  tables>  is  a  list  of  required  relations  necessary 
to  satisfy  the  query,  and  <condition>  identifies  the  tuples  desired  by  evaluation  of  a  boolean 
expression  (corresponds  to  the  relational  algebra  selection  condition  in  a  select  operation 
[EN89]. 

One  departure  from  the  formal  relational  models  is  that  SQL  allows  tuples 
within  a  relation  to  be  repeated.  Thus,  a  relation  in  SQL  is  not  a  set  of  tuples  but  a  multiset 
(orbag)[EN89]. 

Some  current  work  in  the  area  of  query  languages  is  being  done  using  the  idea 
of  a  graphical  interface  for  constructing  queries.  One  such  effort  attempts  to  overcome  the 
difficulties  in  forming  SQL  queries  (ease-of-use)  by  designing  and  implementing  a 
relationally  complete  graphical  dataflow  query  language  (DFQL)  [C191]. 

b.    QUEL 

QUEL  has  similar  functionality  to  SQL;  however,  instead  of  combining 
constructs  from  both  of  the  formal  languages,  it  closely  parallels  tuple  relational  calculus 
[KS86].  Three  types  of  clauses  are  generally  used  to  construct  most  QUEL  queries:  range 
of,  retrieve,  and  where  [KS86].  Range  of  explicitly  declares  the  tuple  variables,  retrieve 
declares  the  attribute  to  retrieve  (corresponds  to  projection  attribute  list),  and  where 
specifies  the  selection  condition  [EN89]. 
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c.    QBE 

Query  by  Example,  QBE,  is  most  closely  related  to  domain  relational 
calculus.  It  is  unique  in  that  it  is  a  two  dimensional  language:  skeleton  tables  (displaying 
the  relation  schema)  are  displayed  pictorially,  and  queries  are  then  expressed  by  filling  in 
an  example  row(s).  When  looking  at  a  QBE  query,  constant  values  appear  without  any 
special  markings  or  indicators  while  domain  variables  (which  do  not  have  to  match  any 
specific  database  values  and  are  completely  arbitrary)  are  indicated  by  being  preceded  by 
an  underscore  ('_').  To  specify  that  the  values  of  a  certain  column  are  to  be  retrieved,  the 
prefix  'P.'  (for  print)  is  used.  [EN89][KS86] 

D.      OBJECT-ORIENTED  DATABASES 

As  with  object-oriented  programming,  the  relatively  new  area  [Ne90a]  of  object- 
oriented  databases  (OODBMS)  does  not  as  yet  have  a  formal  definition/specification  or 
even  an  agreed  upon  informal  definition/specification  [Ed91][US90].  "Object-oriented 
databases  =  object  orientation  +  database  capabilities"  [Kh91,  p.  31]  is  one  attempt  to 
define  OODBMS  s  where  the  database  capabilities  alluded  to  include  persistence, 
transactions,  concurrency  control,  recovery,  querying,  versioning,  integrity,  security,  and 
performance  issues  [Kh91].  This  could  be  rewritten  as  object-oriented  databases  =  object- 

oriented  +  database  capabilities    . 

This  section  provides  a  general  description  of  OODBMS  concepts  along  with  a 
discussion  on  several  OODBMSs  currently  available:  IDB,  Ontos,  Vbase,  Gemstone,  and 
POSTGRES.  Of  the  systems  looked  at,  only  IDB  will  be  given  more  than  a  cursory  look 


13.  [Kh91]  defines  object  orientation  as  abstract  data  types  +  inheritance  +  object  identity,  which  is 
essentially  the  same  definition  previously  used  in  this  paper  for  object-oriented.  For  a  more  in-depth 
discussion  of  OODBMS  concepts  see  [US90]. 
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since  it  is  the  system  used  to  implement  the  Relational/Object-Oriented  Database 
Management  System  in  this  thesis. 

1.     Object-Oriented  Model  Concepts 

The  most  well  known  data  modeling  model  is  the  Entity-Relationship  (ER)  data 
model.  Until  the  late  1970s,  this  model  was  sufficient  for  supporting  the  modeling  needs  of 
conventional  DBMSs  (hierarchical,  network,  and  relational  systems)  that  meet  traditional 
business  data  processing  requirements  [EN89].  The  ER  data  model  is  a  high-level  model 
used  prior  to  actually  developing  a  database  schema  in  a  specific  DBMS.  As  modeling 
needs  have  become  more  complex,  the  ER  data  model  has  become  increasingly  inadequate. 
To  meet  the  needs  for  complex  data  models,  many  data  models  have  been  proposed.  Of 

those  proposed,  they  generally  fall  into  three  categories:  semantic  data  models    ,  functional 
data  models,  and  object-oriented  models  [EN89]. 

In  conventional  DBMSs,  data  is  modeled  using  the  classical  record-oriented  ER 
model.  Here  data  is  looked  at  as  a  group  of  relations  (or  record  types)  that  are  comprised  of 
a  group  of  tuples  (or  records)  which  are  all  stored  in  a  file  [EN89].  Thus,  the  ER  model  must 
be  converted  into  a  DBMS  specific  model  (or  schema)  which  may  lose  its  resemblance  to 
any  real  world  entities  (or  objects)  during  the  conversion  process.  A  good  example  is  that 
of  an  ER  model  for  a  relational  database  application  which  is  converted  to  a  group  of 
relations  that  are  then  normalized.  In  the  normalization  process,  the  original  model  may  be 
distorted  to  such  an  extent  that  any  relationship  to  the  original  real  world  entities  being 
represented  in  the  database  application  is  lost  as  information  is  scattered  among  relations 
[EN89]. 


14.  [EN89]  provides  an  detailed  discussion  of  what  they  term  the  enhanced-ER  model  (EER)  which 
encompasses  what  they  consider  the  most  important  concepts  of  the  semantic  data  model. 
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Of  the  models  mentioned  above,  we  focus  on  the  object-oriented  data  model. 
With  an  object-oriented  model,  a  database  is  considered  group  of  objects  that  represent  real 
world  entities  [EN89].  In  OODBMSs,  objects  are  represented  directly  by  database  objects 
[EN89].  Thus,  there  is  no  loss  of  the  original  model  as  with  the  ER  model;  as  more  complex 
real-world  entities  are  modeled  using  complex  objects,  there  is  a  direct  correspondence 
between  a  real-world  entity  and  its  database  representation.  This  direct  correspondence 
allows  objects  to  maintain  their  integrity  and  identity  which  in  turn  allows  the  objects  to  be 
identified  and  operated  upon  [EN89].  Some  have  gone  so  far  as  to  question  whether  it  is 
meaningful  to  talk  about  an  object-oriented  data  model  [Ki90]  since  object-oriented  data 
model  concepts  and  the  object-oriented  paradigm  are  for  all  practical  purposes  the  same. 

Fundamental  object-oriented  data  model  concepts  include  data  abstraction, 
encapsulation,  object  identity  [Mc91j,  inheritance,  complex  objects,  message  passing,  and 
operator  overloading  (or  polymorphism)  [Ki90].  All  of  these  concepts,  with  the  exception 
of  object  identity,  were  specifically  addressed  previously  in  this  chapter  under  object- 
oriented  programming  concepts.  Generally,  each  object  is  represented  by  an  object 
identifier  that  is  system  generated.  The  identifier  is  independent  from  any  key  attributes 
which  allows  attributes  to  be  modified  without  destroying  the  objects  identity.  [EN89] 

2.     Object-Oriented  Database  Systems 

Persistence  of  objects  is  considered  the  primary  difference  between  OOPLs  and 
OODBMSs  [EN891.  Objects  used  in  an  OOPL  program  exist  only  during  program 
execution  whereas  those  in  OODBMSs  must  exist  permanently  in  secondary  storage  from 
session  to  session.  Thus,  the  OODBMSs  and  OOPLs  are  quite  similar  except  for  additional 
facilities  provided  by  the  OODBMS  system.  By  the  same  token,  OODBMSs  have  similar 
advantages  as  those  of  OOPLs:  expressibility,  reusability,  etc. 
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"The  Object-Oriented  Database  System  Manifesto"15  written  in  1989  by  M. 
Atkinson,  F.  Bancilhon,  D.  DeWitt,  K.  Kittrick,  D.  Maier,  and  S.  Zdonik  for  the  First 
International  Conference  on  Deductive  and  Object-oriented  Databases,  Kyoto,  Japan, 
describes  13  mandatory  characteristics,  listed  in  Figure  13,  for  a  database  system  to  be 
considered  an  OODBMS  [Ed91]. 


1.  supports  complex  objects 

2.  supports  object  identity 

3.  encapsulates  objects 

4.  supports  either  types  or  classes 

5.  classes  or  types  inherit  from  their  ancestors 

6.  do  not  bind  prematurely 

7.  are  computationally  complete 

8.  are  extensible 

9.  data  is  persistent 

10.  manages  very  large  databases 

11.  allow  concurrent  users 

12.  recover  from  software  and  hardware  failures 

13.  have  a  simple  way  to  query  data 


Figure  13  OODBMS  Manifesto 


15.  This  does  not  contain  an  agreed  upon  set  of  characteristics,  rather,  it  is  an  attempt  to  offer  char- 
acteristics for  agreement  within  the  database  community. 
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There  are  some  correlations  that  may  be  made  between  RDBMS  and  OODBMSs 
that  help  to  conceptualize  how  some  of  the  object-oriented  paradigm  relates  to  the 
relational  paradigm.  A  row  in  a  relation  may  be  thought  of  as  an  object  in  an  OODBMS. 
The  set  of  rows  of  a  relation  may  be  equated  to  a  class.  Other  concepts  in  OODBMSs  that 
have  no  correlation  to  anything  in  a  relational  system  include:  methods,  object  identifiers, 
inheritance,  and  encapsulation.  However,  OODBMSs  do  not  have  a  mathematical 
foundation  to  stand  on  as  relational  systems  do.  [Ed91] 

3.     IDB  Object  Database  Overview 

a.    General  Information 

IDB  [Pe91a][Pe91b][Pe91c][Pe91d]  is  a  new  OODBMS  that  first  entered  the 
commercial  market  in  1990  .  However,  it  could  be  considered  to  have  been  in  development 
for  over  a  decade  with  the  design  and  architecture  of  the  Interface  Description  Language 
(DDL),  a  subset  of  which  is  a  fundamental  component  of  the  IDB  system.  IDB  was  built 
from  the  ground  up  as  an  object  database  management  system.  This  is  in  contrast  to  some 
other  database  management  systems  that  claim  to  be  object-oriented  but  are  not  'real' 
object-oriented  systems.  Some  of  these  are  systems  that  have  as  their  kernel  or  core  a 
relational  system  that  has  object-oriented  extensions  added  on  top.  Others  claim  to  be 
object-oriented  but  fall  short  in  fully  implementing  the  concepts  that  comprise  the  object- 
oriented  paradigm:  inheritance,  encapsulation,  polymorphism,  and  abstract  data  types. 

The  current  version  of  IDB  is  1.1.  Version  1.0  ran  on  several  platforms: 
Domain  OS  (680X0),  Sun  3  (680X0),  Sun  SPARC  and  Windows  3.x.  Version  1.1  extends 
this  list  to  include  the  Macintosh,  NeXT,  and  HP-UX  (680X0  and  PA-RISC).  Other  key 
differences  between  the  version  1.0  and  1.1  include:  supported  platforms  that  are 
networked  together  can  now  share  data  over  the  network;  attributes  may  be  removed  from 
a  schema  without  having  to  modify  the  ASCII  form  file;  ease  of  access  to  menu  facilities 
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has  increased;  development  tools  may  be  used  with  Windows  3;  and  bugs  have  been 
removed  that  existed  in  version  1.0.  [Pe91b] 

Persistent  Data  Systems,  the  designer  and  developer  of  IDB,  describe  IDB  as 
"an  object  database  for  software  developers  who  build  applications  that  must  manage 
complex  shared  data"[Pe91d,  p.  3].  Applications  suited  for  use  with  IDB  include  CASE, 
CAD,  image  management  systems,  hypertext  systems,  hypermedia  systems  and  geographic 
information  systems.  This  list  is  not  intended  to  be  all  inclusive,  but  rather  to  give  the  reader 
an  idea  of  the  types  of  applications  with  requirements  to  model,  manage,  and  store  complex 
and  unconventional  data.  [Pe91d] 

The  data  definition  language  (or  schema  language),  IDL,  extends  Kernighan 
and  Ritchie  (K&R)  C  [KR78]  to  include  object-oriented  capabilities.  Polymorphism, 
multiple  inheritance,  and  dynamic  binding  and  loading  are  among  these  capabilities. 
Because  IDB  uses  K&R  C,  tools  available  for  working  with  C  (such  as  the  C  compiler  and 
on-line  debugger)  on  each  supported  platform  may  be  used  in  the  development  of  IDB 
applications.  [Pe91d] 

IDL  facilitates  the  interface  between  C  and  IDB.  The  interface  can  be  thought 
of  as  consisting  of  three  parts:  core  interface,  display  manager  interface,  and  browser 
interface.  The  core  interface  allows  IDB  applications  to  have  object-oriented  capabilities. 
Display  management  for  stand  alone  applications  uses  the  display  manager  interface.  This 
interface  is  not  exclusive  to  stand  alone  applications  since  its  features  can  also  be  accessed 
from  within  the  browser.  The  browser  interface  has  the  features  of  the  display  manager 
interface  in  addition  to  other  special  features  only  available  in  the  browser.  [Pe91d] 

b.    Clusters  and  Structures 

A  key  concept  in  IDB  is  that  of  a  'cluster'.  This  term  is  used  in  both  the 
logical  and  physical  sense.  That  is,  the  term  cluster  when  used  in  the  context  of  computer 
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science  generally  brings  to  mind  clustering  in  memory.  However,  the  word  cluster  in  the 
strict  sense  means  to  gather  things  together.  In  IDB,  a  cluster  is  a  gathering  of  objects  or  a 
group  of  objects.  An  object  cannot  be  in  more  than  one  cluster.  Since  IDB  is  built  as  a  multi- 
user system,  it  also  includes  facilities  for  concurrent  access  control.  Clusters  are  important 
in  maintaining  the  access  control.  "The  cluster  is  the  unit  of  data  transfer  and  the  unit  of 
locking  for  control  of  concurrent  access"  [Pe91d,  p.  3]. 

Persistent  Data  Systems  describes  an  IDB  database  as  "a  set  of  objects 
connected  by  references"  [Pe91c,  p.  6].  Since  a  cluster  is  a  group  of  objects,  then  an  IDB 
database  is  simply  a  set  of  clusters  connected  by  references.  There  are  two  kinds  of 
references  in  IDB:  local  references  and  cross  references.  The  names  themselves  are  quite 
descriptive.  Local  references  are  those  references  between  objects  of  the  same  cluster. 
Cross  references,  on  the  other  hand,  are  between  objects  belonging  to  different  clusters. 
[Pe91d] 

Access  to  clusters  is  gained  by  opening  a  transaction  on  the  cluster.  It  is  at  this 
time  that  the  cluster  is  read  in  from  secondary  storage  into  main  memory.  Local  references 
are  made  by  using  pointers  to  the  object  being  referenced.  Cross  references  may  also  use 
pointers  if  the  cluster  containing  the  object  they  reference  is  already  present  in  memory 
(i.e.,  a  transaction  is  also  open  on  that  cluster).  The  other  possibility  is  that  the  object  being 
cross  referenced  is  not  in  main  memory.  This  case  is  resolved  by  using  unique  identifiers 
that  IDB  issues  to  every  object.  [Pe91d] 

IDB  guarantees  that  every  object  created  will  have  a  unique  identifier.  This 
identifier  is  not  only  unique  to  the  cluster,  system,  platform,  etc.;  it  is  unique  universally. 
That  is,  an  object  created  by  IDB  on  any  platform  can  be  ported  to  any  other  platform  and 
still  be  guaranteed  that  the  identifier  is  unique.  This  allows  different  platforms  networked 
together  to  share  IDB  files  without  object  identification  problems.  Thus,  "no  two  objects 
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will  ever  have  the  same  identity  and  an  object  will  maintain  its  identity  even  when  moved 
from  place  to  place"  [Pe91d,  p.  4]. 

Several  identifiers  are  needed  to  accomplish  this:  master  identifiers  (MID), 
cluster  identifiers  (CID),  object  identifiers  (OID),  and  local  identifiers  (LID).  During 
installation,  a  unique  MID  is  set  up  that  is  assigned  to  each  copy  of  IDB  by  Persistent  Data 
Systems.  When  a  cluster  is  created,  the  MID  is  combined  with  further  numerical  identifiers 
to  form  the  CID.  Finally,  the  OID  is  composed  of  the  CID  and  the  LID  which  uniquely 
identifies  the  object  within  the  cluster.  [Pe91d] 

Each  cluster  is  described  by  an  Interface  Description  Language  (IDL) 
structure.  The  structure  contains  all  the  necessary  types  to  describe  the  objects  of  a  cluster. 
In  other  words,  it  contains  the  schema  for  the  cluster  specified  in  IDL.  The  IDL  structure  is 
really  the  "description  of  structural  constraints  on  data"  [NMSW83,  p.  7].  The  fundamental 
IDL  model  is  predicated  upon  the  directed  attribute  graph.  An  example  of  a  directed 
attribute  graph  is  given  in  Figure  14. 

A  directed  attribute  graph  is  composed  of  a  set  of  typed  nodes  that  possess  a 
set  of  attributes.  The  type  of  a  node  determines  the  particular  set  of  attributes  it  will  contain. 
The  attributes  are  either  a  primitive  value  (the  value  is  embedded  in  the  node  and  is  either 
boolean,  integer,  or  rational)  or  a  node-value  (a  pointer  to  another  node).  In  Figure  14,  the 
attributes  with  node-values  have  pointers  which  are  the  directed  edges  in  the  graph  pointing 
to  other  nodes.  Each  graph  must  have  a  root  node  that  allows  all  other  nodes  to  be  reached 
by  following  some  path  along  different  attribute  edges  from  the  root  to  the  nodes.  "An  IDL 
structure  specifies  a  related  class  of  attributed  directed  graphs  by  listing  the  set  of  node 
types,  the  attributes  of  each  node  type,  and  the  type  of  the  root"  [NMSW83,  p.  7]. 
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Figure  14  An  Example  of  a  Directed  Attribute  Graph  [NMSW83,  p.  8] 

c.    Nodes,  References  and  Attributes 

Every  IDB  object  must  have  a  type  and  can  only  be  in  one  cluster.  The  types 
that  an  object  may  have  are  defined  through  the  class  structure  that  is  delineated  in  the 
cluster  schema.  In  IDB,  only  classes  which  have  no  subclasses  can  be  instantiated  as 
objects.  These  classes  are  called  nodes  and  have  the  type  node  type.  In  the  class  hierarchy, 
the  nodes  are  the  leaves  of  the  class  structure.  This  is  something  of  a  departure  from  the 
standard  object-oriented  concept  of  a  class  since  only  leaf  classes  can  be  instantiated. 
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However,  any  class  that  is  not  a  leaf  can  always  be  made  a  leaf  (in  a  logical  way)  by 
instantiating  a  subclass  of  the  class  to  only  inherit  all  attributes  and  methods  of  its 
superclass.  That  is,  it  is  a  leaf  which  is  a  copy  of  its  superclass  except  that  the  superclass 
has  subclasses  and  the  leaf  (by  definition)  does  not.  Other  class  types  that  are  not  node  types 
are  said  to  be  strict  class  types. 

Consider  the  graph  presented  in  Figure  15,  which  is  derived  from  the  example 
IDL  schema  (included  as  APPENDIX  A)  from  the  IDB  User's  Manual  [Pe91d,  p.  32].  It  is 
clear  from  the  graph  that  the  leaf  nodes  are  ptrain,  ftrain,  fplane,  and  pplane.  These  classes 
are  IDB  node  types  and  may  be  instantiated  to  IDB  objects.  The  other  classes  are  used  to 
build  the  attributes  and  methods  of  the  node  types  but  may  not  be  instantiated  into  objects. 
These  strict  class  types  delineate  attributes  and  methods  that  are  common  to  all  of  their 
descendants  [New86].  IDB  also  supports  the  idea  of  multiple  inheritance.  Thus,  in  our 
example,  ptrain  inherits  all  of  the  attributes  and  methods  of  class  types  passenger  and  train. 


vehicle 

freight 
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Figure  15  A  Class  Hierarchy 

Newcomer  likens  the  IDL  node  type  to  the  idea  of  a  record  type  in  other 
languages[New86].  Record  fields  are  similar  to  a  node's  attributes[New86].  There  are  two 
kinds  of  references  which  connect  objects:  local  references  and  cross  references.  All 
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references  must  also  have  a  type;  however,  unlike  objects  which  can  only  have  node  types, 
references  can  have  the  type  of  any  class  in  the  cluster.  A  references  of  a  certain  type  can 
point  to  any  class  of  that  type  or  any  of  its  descendants  (if  the  class  is  not  a  node).  Thus,  a 
reference  of  type  train,  in  Figure  15  above,  could  point  to  a  train,  a  ptrain,  or  a  ftrain. 

From  the  root  reference  of  any  cluster,  all  objects  within  that  cluster  must  be 
reachable  by  following  some  path  along  references  in  the  cluster.  Two  objects  may  have 
attributes  that  reference  the  same  object.  In  this  way,  references  facilitate  sharing. 
References  are  also  allowed  to  create  cycles  within  a  cluster. 

There  is  another  possibility  for  the  type  of  a  reference:  universal  types.  The 
types  discussed  up  to  this  point  have  all  been  associated  with  a  particular  cluster.  Universal 
types  allow  references  to  refer  to  an  object  in  any  cluster.  The  universal  types  and  their 
relation  to  each  other  is  shown  in  Figure  16.  [Pe91c] 
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Figure  16  Universal  Types  [Pe91c,  p.  36] 
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d.    Transactions 

Since  IDB  is  a  multi-user  system,  concurrency  control  must  be  maintained. 
Transactions  are  used  to  implement  concurrent  access  control  to  clusters.  Additionally, 
transactions  guarantee  that  cluster  updates  are  all  or  nothing.  That  is,  the  entire  cluster  is 
updated  or  nothing  in  the  cluster  gets  updated.  Thus,  cluster  modifications  are  'atomic'. 
[Pe91c][Pe91d] 

Transactions  allow  users  to  read  and  write  clusters.  Access  to  a  cluster  is 
determined  by  one  of  four  types  of  transactions:  write,  create,  read,  and  examine.  To 
modify  an  object,  a  write  transaction  must  be  open.  Examine  and  read  transactions  allow 
different  forms  of  parallel  access  to  a  cluster  by  one  or  more  user.  New  cluster  values  are 
created  by  the  create  transaction.  A  series  of  'roll-back'  points  may  be  established  by  nested 
write  transactions.  An  arbitrary  number  of  write  transactions  may  be  nested  within  other 
create  or  write  transactions.  Large  and  complex  modifications  are  facilitated  in  this  manner. 
[Pe91d] 

Reading  and  traversal  of  cluster  objects  and  the  ability  to  use  those  objects 
and  their  associated  attributes  to  set  values  of  browser  variables  is  possible  during  read 
transactions.  While  a  read  transaction  is  open  on  a  cluster,  no  write  or  create  transaction  on 
that  cluster  is  allowed.  Similarly,  only  while  no  write  or  create  transaction  is  open,  may  a 
read  transaction  be  opened.  This  guarantees  that  the  cluster  being  viewed  in  memory  is  the 
same  as  that  cluster  on  secondary  storage. 

Examine  transactions  are  similar  to  read  transactions  except  that  it  does  not 
stop  a  write  transaction  from  being  opened  and/or  committed  on  the  same  cluster.  Thus,  the 
cluster  being  viewed  in  memory  may  be  different  (older)  than  that  cluster  on  secondary 
storage.  This  transaction  can  be  opened  at  any  time.  It  allows  a  greater  amount  of 
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concurrent  use  of  the  system.  Clearly,  this  kind  of  transaction  should  only  be  used  when 
viewing  the  most  current  instance  of  the  database  is  not  necessary. 

Modification  of  cluster  objects  and  their  associated  attributes  is  accomplished 
using  either  a  create  or  write  transaction.  Modifications  made  to  the  cluster  are  not  written 
back  to  secondary  storage  until  the  transaction  is  committed.  If  after  modifying  the  objects 
of  a  cluster  in  memory,  it  is  determined  that  the  modifications  are  unwanted,  then  the 
transaction  may  be  aborted.  In  this  case,  that  cluster  in  secondary  storage  remains 
unchanged.  It  is  important  to  note  that  during  a  write  or  create  transaction,  one  or  more 
examine  transactions  may  be  open  on  the  same  cluster. 

A  special  case  of  the  write  transaction  is  the  create  transaction.  Create 
transactions  may  only  be  opened  during  entry  to  a  cluster.  They  are  used  if  no  cluster  file 
exists  on  secondary  storage  or  if  the  cluster  file  that  does  exist  is  no  longer  wanted.  The 
create  transaction  creates  a  legal  value  to  which  the  cluster  root  is  set.  Once  the  create 
transaction  is  committed,  then  the  created  cluster  and  any  other  objects  created  during  the 
open  transaction  are  written  to  the  cluster  file  on  secondary  storage. 

4.     Other  Systems 

a.    ONTOS/Vbase 

Vbase,  a  single-user  system,  a  product  of  Ontologic  Inc.  (now  named  Ontos 
Inc.)  released  in  1988,  had  several  problems  that  caused  it  to  flop.  First,  it  had  several 
language  problems.  The  Type  Definition  Language  (TDL)  was  a  nonstandard  language 
which  was  plagued  by  many  inherent  problems  associated  with  nonstandard  languages. 
TDL  was  used  for  schema  definition  and  abstract  object  interface  specification  [HW91]. 
Their  object  manipulation  language  was  an  object-oriented  extension  of  the  C  language, 
called  a  compiled  procedural  language  (COP)   [HW91].  In  addition  to  impedance 

mismatch     problems  produced  by  these  languages,  Ontologic  had  to  do  everything  to 
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support  the  languages  and  the  languages  had  not  passed  the  test  of  time.  Additionally,  there 
was  a  lack  of  tools  needed  to  work  with  the  languages.  [In89] 

ONTOS  is  the  successor  to  Vbase  [AHS91].  It  runs  under  UNIX,  AIX,  or  OS/ 
2  [In89].  The  design  goal  of  ONTOS  is  that  the  system  should  allow  trade-off  decisions 
between  performance,  formalism,  and  safety  to  be  made  by  the  user  [AHS91].  The  system 
allows  the  user  to  directly  access  objects  through  direct  references.  In  this  manner,  the  user 
may  bypass  system  mechanisms,  controlling  low-level  detail  to  enhance  performance  if 
deemed  critical  to  performance.  ONTOS  also  supports  C++,  overcoming  the  nonstandard 
language  problem  of  Vbase[In89].  Additionally,  it  provides  a  class  library  to  enhance  its 
modeling  power.  It  also  has  no  need  for  a  schema  definition  language  since  it  operates  on 
class  definitions  in  C++  directly.  Versioning,  an  alternative  mechanism,  a  graphical 
browser,  an  integrated  object  SQL,  and  a  multi-user  capability  on  a  homogeneous  network 
also  exist  in  ONTOS.  [AHS91] 

b.    GemStone 

The  Servio  Logic  Corporation  produces  GemStone17  [BM089][HW91],  a 
disk-based  storage  manager  designed  for  commercial  and  engineering  markets  [BOS91]. 
The  designers  of  GemStone  surveyed  object-oriented  extensions  to  C,  Pascal,  and  the 
OOPL  Smalltalk  before  deciding  to  develop  their  own  OOPL,  OPAL,  a  modified  version 
of  Smalltalk-80  [HW91].  OPAL  is  GemStone's  data  definition  language/data  manipulation 
language,  which  is  also  used  for  general  computations/queries  [BM089].  Since  it  only  uses 


16.  When  information  must  pass  between  two  structurally  and  semantically  different  languages  im- 
pedance mismatch  may  occur  [HW91].  Database  systems  that  use  two  different  languages  in  their 
implementation  often  have  one  that  is  a  procedural  language  (conventional)  and  the  other  a  more  de- 
clarative, higher-level  language  which  results  in  a  mismatch  of  two  language  paradigms  [Kh91]. 

17.  The  current  version  of  GemStone  is  Release  4.0 
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one  language,  OPAL,  for  programming,  it  bypasses  the  problem  of  impedance  mismatch 
[HW91].  GemStone  provides  an  interface  to  several  procedural  languages:  C,  C++,  and 
Smalltalk  [BOS91]. 

Visual  Schema  Designer  (GS  Designer)  and  Tool  Suite  are  two  graphical 
tools  which  are  included  with  GemStone.  The  GS  Designer  allows  GemStone  class 
definitions  to  be  modified,  deleted,  and  created  using  a  keyboard  and  mouse  interface  along 

1 8 

with  bitmapped  graphics  in  a  windows  environment.  The  class  graph  is  the  primary 
organizing  principle  of  the  GS  Designer.  Both  a  high-level  application  development 
environment  and  a  visual  programming  environment  are  integrated  by  the  graphical  tool 
'tool  suite'.  Motif  and  OpenLook  are  both  supported  by  tool  suite.  [BOS91] 

Recently,  Servio  Corp.  introduced  a  collection  of  development  tools  that 
facilitate  object-oriented  financial,  scientific,  and  manufacturing  systems  construction  by 
application  developers.  This  tool  collection  is  called  the  GemStone  Object  Database 
Development  Environment,  Geode.  Geode  is  comprised  of  four  components:  the  forms 
designer,  the  visual  program  designer,  the  application  designer,  and  the  system 
programmer  tools.  The  forms  designer  facilitates  the  construction  of  screens  for  database 
information  display,  update,  and  insertion.  The  visual  program  designer  comes  with  a  set 
of  basic  libraries,  which  may  be  extended  by  the  user,  and  applications  to  be  developed 
graphically  without  writing  code.  The  products  of  both  the  forms  designer  and  the  visual 
program  designer  are  combined  into  complete  applications  by  the  application  designer. 
Finally,  debuggers,  cross-reference  tools,  graphical  browsers,  and  performance  profilers 
comprise  the  system  programmer  tools.  [Sc91] 


18.  A  named  group  of  classes  interrelated  by  various  types  of  relationships  (including  generalization, 
association,  and  aggregation)  is  called  a  class  graph.  All  GemStone  class  graphs  have  the  predefined 
Object  class  as  its  root.  [BOS91] 
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GemStone  supports  several  relational  gateways.  That  is,  it  supports  SQL 
access  to  the  external  databases  Sybase,  Ingres,  Oracle,  and  Informix.  SQL  query  results 
may  be  viewed  as  objects  using  these  gateways  which  provides  interoperability  with 
relational  databases.  The  translation  between  the  systems  is  facilitated  using  generic  row 
(tuple/record)  and  relation  classes  that  may  be  specialized  by  the  user  by  defining 
subclasses  these  generic  classes.  [BOS91] 

c.     POSTGRES 

POSTGRES19  is  the  successor  to  the  INGRES  relational  DBMS,  and  has 
been  under  development  since  1986  under  the  leadership  of  Professor  Stonebraker  at  the 
University  of  California,  Berkeley  [St91b][SK91].  POSTGRES  is  often  listed  under  the 
heading  of  OODBMSs.  However,  it  is  more  than  that  since  it  also  supports  knowledge 
management.  Actually,  it  is  an  extension  of  the  traditional  RDBMS  that  supports  complex 
objects;  inheritance;  methods  and  functions  in  the  database;  and  contains  both  a  complete 
rule  system  and  an  abstract  data  type  system  [St91b].  POSTGRES  n,  the  successor  to 
POSTGRES  is  in  the  design  process  and  will  try  to  manage  main-memory  data,  disk-based 
data,  and  archive-based  data  in  a  unified,  elegant  manner  [BOS91]. 

The  objectives  of  the  designers  of  POSTGRES  are  to  [Da90]: 

•  provide  better  support  for  complex  objects, 

•  provide  user  extendability  for  data  types,  operators,  and  access  methods, 

•  provide  active  database  facilities  (alerters  and  triggers)  and  inferencing 
support, 

•  simplify  the  DBMS  code  for  crash  recovery, 


19.  POSTGRES  stands  for  Post  INGRES  and  its  current  version  is  3.0  [RK][SK91]. 
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•  produce  a  design  that  can  take  advantage  of  optical  disks,  multiple-processor 
workstations,  and  custom-designed  VLSI  chips,  and 

•  make  as  few  changes  as  possible  (preferably  none)  to  the  relational  model. 

E.      PREVIOUS  WORK 

In  1988,  Michael  L.  Nelson  completed  the  fundamental  work  in  this  area.  Nelson's 
primary  goal  was  to  design  a  Relational  Object-Oriented  Management  System  (ROOMS) 
that  could  be  implemented  in  almost  any  commercial  object-oriented  database  or  any 
object-oriented  programming  language  [Ne88].  Stephen  C.  Filippi  expanded  the  work  done 
by  Nelson  with  the  completion  of  his  Master's  Thesis,  Implementing  Relational  Operations 
In  An  Object-Oriented  Database,  in  1992  [Fi92]. 

1.     ROOMS 

ROOMS  is  the  foundation  upon  which  this  thesis  is  built.  ROOMS  is  a  feasibility 
study  to  show  that  the  relational  data  model  need  not  be  discarded  in  moving  to  object- 
oriented  systems,  and  to  allow  the  additional  capabilities  of  the  object-oriented  paradigm 
realization  within  conventional  applications  by  removing  limitations  on  data  types 
[Ne88][NMO90]. 

The  fundamental  structure  of  ROOMS  is  almost  as  simple  as  the  relational  system 
it  imitates.  An  object  that  is  a  collection  of  tuples  (records)  is  a  relation.  An  object  that  is  a 
collection  of  fields  is  a  record.  Objects  that  are  user-defined  class  instantiations  are  fields. 
In  ROOMS,  all  records  of  a  relation  must  have  identical  format.  Distinction  between 
complex  and  simple  objects  are  not  made:  no  data  type  limitations.  [Ne88][NMO90] 

To  show  that  ROOMS  is  feasible,  the  five  fundamental  relational  algebra 
operations  (selection,  union,  set  difference,  Cartesian  product,  and  projection),  which 
constitute  the  basis  for  all  other  relational  operations,  were  implemented  in  a  LISP-based 
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OOPL,  PC  Scheme  (PCS).  However,  PCS  has  no  facilities  for  object  persistence  so  the  data 
in  this  implementation  is  lost  from  one  session  to  another.  [Ne88] 

2.     Implementing  Relational  Operations  in  Prograph 

This  work  continues  the  concepts  of  ROOMS  by  implementing  the  five 
fundamental  relational  algebra  operations  in  Prograph,  an  OOPL.  The  fundamental 
contribution  of  this  work  is  that  of  object  persistence.  Even  though  Prograph  is  not  an 
OODBMS,  it  contains  primitive  operations  that  allow  for  reading  and  writing  database  files 
to  secondary  storage  and  for  complex  data  type  manipulation  [Fi92].  The  natural  step  that 
follows  is  to  actually  implement  ROOMS  in  a  commercially  available  OODBMS,  which  is 
the  thrust  of  this  thesis. 
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HI.  DETAILED  PROBLEM  STATEMENT 

A.  GENERAL 

The  focus  of  previous  chapters  has  been  to  provide  the  reader  with  a  very  brief 
introduction  to  the  motivation  and  topic  of  this  work,  a  discussion  of  fundamental  concepts 
necessary  for  a  more  complete  understanding  of  this  thesis,  and  a  point  of  departure  for  this 
and  future  chapters.  The  purpose  of  this  chapter  is  to  provide  an  overview  of  some 
limitations  associated  with  RDBMSs  and  OODBMSs,  along  with  a  discussion  of  the 
rationale  for  a  combined  R/OODBMS  approach.  In  general,  the  limitations  of  RDBMSs 
tend  to  be  the  strengths  of  OODBMSs  and  the  limitations  of  OODBMSs  the  strengths  of 
RDBMSs. 

B.  RELATIONAL  DATABASE  LIMITATIONS 

RDBMSs  use  a  very  simple  data  structure,  the  idea  of  a  table  (rows  and  columns),  and 
are  based  upon  a  strong  mathematical  foundation,  predicate  logic  and  set  theory.  Primarily 
because  of  these  two  factors,  RDBMS  became  widely  accepted  for  business  applications 
over  the  older  and  more  awkward  hierarchical  and  network  database  technologies. 
However,  RDBMSs  have  a  severe  limitation:  the  inability  to  deal  with  complex  data.  It  is 
the  RDBMS 's  simplicity,  along  with  its  mathematical  foundation  and  its  complex  data 
limitation,  that  are  basis  for  this  thesis. 

1.     Simple  Data  Types 

For  years,  RDBMS  have  provided  excellent  performance  for  traditional,  well 
established  business  data  processing  applications.  Their  standard  fixed  collection  of  data 
types  (integers,  rationals,  strings,  etc.)  were  sufficient  to  allow  RDBMSs  to  function  well. 
Now,  as  more  complex  data  needs  have  developed  within  the  business  sector,  particularly 
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in  the  engineering  arena,  it  has  become  clear  that  this  simple  collection  of  data  types  is  no 
longer  adequate.  Although  relational  systems  have  not  outgrown  their  usefulness  as 
traditional  business  database  needs  will  always  exist,  there  is  definitely  a  need  for 
something  to  overcome  their  limited  data  types. 

Some  current  RDBMSs  provide  the  ability  to  include  digitized  pictures  in  their 
database  applications.  However,  none  provide  the  ability  to  include  more  complex  data 
structures  such  as  sounds,  animated  graphics,  and  extremely  large  and  complicated  inter- 
relationships among  relations  within  a  database,  to  name  some  of  the  primary  ones. 
Although  some  relational  systems  have  been  extended  to  include  some  of  these  complex 
data  types,  they  generally  do  not  include  inheritance,  encapsulation,  and  other 
characteristics  of  the  object-oriented  paradigm. 

As  RDBMSs  attempt  to  maintain  more  complicated  data  relationships, 
performance  of  the  system  is  degraded.  The  normalization  process  used  in  designing  the 
database  schema  to  represent  complex  data  cause  many  small  relations  to  exist  within  the 
database.  As  queries  are  made  of  the  database,  many  join  operations  are  then  needed  to 
answer  the  query.  Since  join  operations  are  very  expensive  in  terms  of  performance,  the 
system  tends  to  provide  poor  performance.  However,  in  OODBMS  this  problem  is  avoided 
since  these  complex  relationships  can  be  represented  with  complex  objects  that  have  an 
explicit  link  between  component  objects.  Thus,  the  need  for  numerous  joins  is  avoided  and 
performance  is  increased. 

When  modeling  real  world  entities,  the  relational  model  uses  relations  (flat 
objects)  to  represent  them.  During  the  normalization  process,  the  relations  in  a  database 
schema  are  further  flattened  out  into  a  number  of  smaller  relations.  This  decomposition  of 
real  world  entities  into  smaller  flat  relations  represents  a  loss  of  abstraction.  For  example, 
in  the  previous  chapter  there  was  a  real  world  entity  that  was  represented  by  the  relation 
Officer  in  a  military  database.  A  database  containing  the  Officer  relation  might  also  have  a 
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relation  called  Dependents  to  represent  the  real  world  entities  that  are  dependents  of 
military  officers.  However,  this  is  not  a  very  good  abstraction.  A  better  abstraction  for  these 
two  real  world  entities  in  a  military  database  is  to  have  the  Officer  relation  contain  one  more 
attribute:  Dependents.  But,  this  attribute  would  be  multi-valued  which  is  not  consistent 
with  the  requirement  that  all  attributes  in  a  relational  database  be  atomic.  Therefore,  multi- 
valued attributes  are  not  supported  in  RDBMSs. 

Continuing  with  the  previous  example,  it  can  be  seen  that  when  an  Officer  tuple 
is  retrieved  there  is  direct  access  to  the  dependent  data  also.  However,  if  two  relations  were 
used,  then  a  join  operation  would  be  needed  to  associate  an  Officer  tuple  with  that  officer's 
associated  dependents.  This  is  a  very  simple  example;  however,  the  reader  can  imagine  that 
if  the  complexity  of  this  type  of  situation  is  increased  several  orders  of  magnitude,  then 
surely  a  RDBMS  would  provide  poor  performance  in  responding  to  queries  of  this  nature. 

2.     Tuple  Function 

As  stated  previously,  relational  databases  are  based  on  the  simple  data  structure 
of  a  table  of  values  of  simple  types.  Displaying  the  values  of  a  tuple  in  a  relational  database 
system  is  generally  straight  forward  since  the  values  are  generally  simple  text  or  numbers 
that  the  database  can  easily  handle  with  ASCII  characters.  For  traditional  business  data 
processing  applications,  this  is  certainly  sufficient.  However,  databases  that  contain  more 
complex  attribute  values  (such  as  sounds,  graphics,  video,  etc.)  are  not  so  simple. 

Consider  a  database  of  machine  parts  that  contains  as  an  attribute  a  3-D  image  of 
each  part  along  with  more  traditional  attributes,  cost,  part  number,  size,  weight,  quantity  on 
hand,  etc.  If  a  user  wants  to  display  a  the  3-D  image  of  a  particular  part,  then  the  part  tuple 
retrieved  requires  some  method  of  displaying  this  attribute  since  a  general  RDBMS  that 
was  not  designed  for  this  specific  application  will  not  be  able  to  display  this  attribute. 
However,  an  OODBMS  could  handle  this  situation  by  having  a  Display  method  for  Part 
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objects  which  would  display  the  3-D  image.  Since  OODBMSs1  allow  objects  to  have 
methods  defined  for  them,  any  OODBMS  would  suffice  to  construct  and  maintain  this 
machine  parts  database.  This  is  in  contrast  to  a  RDBMS  that  would  have  to  be  developed 
specifically  for  this  application  since  the  data  does  not  contain  any  functionality  that  could 
be  used  to  determine  how  to  handle  it. 

3.     Inheritance 

Relations  in  a  relational  database  lack  the  ability  to  define  a  new  relation  based  on 
an  existing  relation.  That  is,  a  new  relation  cannot  be  created  that  has  a  schema  that  only 
lists  new  attributes  to  be  added  to  the  schema  for  an  already  existing  relation.  For  example, 
assume  that  a  relational  database  has  a  relation  called  Person  that  has  the  following 
attributes:  name,  weight,  birthdate,  color  eyes,  and  color  hair.  Now  we  wanted  to  add  a  new 
relation,  Officer,  that  has  all  the  characteristics  (attributes)  of  Person  but  also  has  attributes 
rank,  branch  of  service,  and  unit.  It  is  desirable  to  allow  Officer  to  inherit  the  attributes  of 
Person.  The  usefulness  of  inheritance  is  more  evident  if  we  consider  that  we  also  want  to 
have  another  new  relation,  Enlisted,  that  has  the  characteristics  of  Person  along  with 
enlistment  date,  rank,  ETS,  etc.  Now  we  have  two  relations  that  have  the  characteristics  of 
Person  but  do  not  have  to  redefine  the  common  Person  attributes  in  each  of  the  new 
relations.  In  a  relational  system,  these  common  attributes  cannot  be  inherited  but  each  new 
relation  has  to  have  them  explicitly  included  in  their  schema. 

Using  the  object-oriented  paradigm,  inheritance  is  included  by  definition  and 
supports  code/schema  reuse  by  allowing  an  object  to  be  further  specialized  by  the  definition 


1.  It  is  realized  that  there  is  no  standard  definition  for  an  OODBMS  however,  in  all  cases  it  is  gen- 
erally agreed  that  for  a  DBMS  to  be  considered  object-oriented  that  it  must  manage  objects  that  have 
attributes  and  methods  associated  with  them. 
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of  a  subclass  that  inherits  all  of  the  attributes  of  its  superclass.  In  our  example,  both  Officer 
and  Enlisted  would  be  subclasses  of  the  class  Person.  Now,  any  instance  of  an  Officer  or 
an  Enlisted  will  include  the  common  Person  attributes  without  having  them  explicitly 
defined  in  the  class  definition  for  Officer  or  Enlisted. 

4.     Impedance  Mismatch 

With  many  conventional  database  systems  (relational,  hierarchical,  and  network), 
there  is  generally  the  problem  of  impedance  mismatch.  That  is,  they  generally  have  one 
language  for  data  queries  and  another  for  data  manipulation.  In  the  relational  case,  a  query 
language  like  SQL  may  be  used  but  then  the  actual  data  in  the  database  is  manipulated  using 
a  conventional  programming  language.  Thus,  there  is  a  mismatch  by  mixing  the  generally 
procedural  conventional  language  with  the  more  declarative  query  language  along  with 
their  differing  data  structures  [Kh91].  In  OODBMSs,  there  is  a  closeness  between  data  and 
programs  where  a  single  language  has  the  expressive  power  and  flexibility  to  allow  both 
data  queries  and  manipulation. 

C.     OBJECT-ORIENTED  DATABASE  LIMITATIONS 

Many  feel  that  OODBMSs  are  here  to  stay  and  that  they  are  the  next  logical  step  in 
the  evolution  of  database  technology.  However,  there  still  exist  two  primary  drawbacks  to 
them  which  limit  their  acceptance  as  the  answer  to  tomorrow's  database  requirements:  (1) 
the  lack  of  a  theoretical  basis  and  (2)  no  universally  accepted  standard  definition.  Neither 
of  these  limitations  exist  in  relational  database  model  which  has  played  a  large  role  in  the 
overall  acceptance  of  relational  model.  Thus,  there  is  no  reason  why  a  more  expressive  and 
powerful  model  that  can  easily  have  relational  databases  mapped  onto  it  and  overcomes 
these  limitations  cannot  become  widely  accepted  for  tomorrow's  applications. 
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1.  Mathematical  Foundation 

Any  query  language  in  a  relational  system  must  be  relationally  complete2.  Thus, 
RDBMS  users  are  guaranteed  that  their  queries  will  be  answered  correctly  by  any  RDBMS 
system  since  relational  algebra  is  based  on  mathematical  set  theory  and  relational  calculus 
is  based  on  mathematical  predicate  logic  [EN89].  Queries  in  any  language  can  be  reduced 
to  a  mathematical  premise  and  be  mathematically  shown  to  be  true.  This  is  not  the  case  with 
OODBMSs  which  have  no  such  theoretical  basis. 

2.  Standardization 

Possibly  more  serious  than  the  non-existence  of  a  formal  theoretical  basis  is  the 
lack  of  a  universally  accepted  standard  definition,  which  may  be  considered  one  of  the 
relational  model's  stronger  features.  Since  relational  databases  have  a  universally  agreed 
upon  definition  and  underlying  theoretical  foundation,  different  commercial  RDBMSs  are 
functionally  equivalent.  Standardization  leads  to  many  advantages  such  as  better  support, 
portability  among  different  systems,  greater  acceptance,  common  evaluation  criteria,  etc. 
The  OODBMS  community  lacks  anything  close  to  a  standard  or  even  a  generally  accepted 
definition. 

Not  only  is  there  no  standard  definition  or  specification,  but  the  object-oriented 
community  cannot  even  agree  upon  terminology  [Ed91][Ne91].  It  is  even  more  difficult  to 
define  something  when  people  cannot  even  agree  on  the  terminology  that  is  used  to 
describe  it.  Thus,  when  a  database  or  any  other  software  product  is  said  to  be  object- 
oriented,  the  user  cannot  be  sure  what  that  means.  Since  'object-oriented'  is  a  hot 


2.  Recall  that  relational  calculus  and  relational  algebra  are  equivalent.  Thus,  it  is  also  correct  to  say 
any  query  language  must  have  the  expressibility  of  relational  calculus  or  relational  algebra.  In  either 
case,  a  language  that  satisfies  this  requirement  is  said  to  be  relationally  complete. 
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buzzword,  it  is  found  in  advertising  for  products  that  may  have  little  to  do  with  the  object- 
oriented  paradigm.  This  brings  to  mind  a  quote  used  earlier:  "I  have  a  cat  named  Trash.  In 
the  current  political  climate,  it  would  seem  that  if  I  were  trying  to  sell  him  (at  least  to  a 
Computer  Scientist),  I  would  not  stress  that  he  is  gentle  to  humans  and  is  self-sufficient, 
living  mostly  on  field  mice.  Rather,  I  would  argue  that  he  is  object-oriented"  [Kin89,  p.  23]. 
The  bottom  line  is  that  the  object-oriented  community  suffers  from  definition  overloading. 
This  lack  of  standardization  has  also  been  problematic  in  that  there  are  no 
standard  benchmarks  upon  which  to  evaluate  OODBMS  performance  [St91c].  Portability 
between  systems  is  poor  since  no  single  OODBMS  data  model  exists  along  with  a  standard 
core  set  of  operations  [Ed91].  OODBMS s  differ  among  themselves  on  whether  they  have 
a  class  library  available  and  what  classes  are  provided  in  the  library  if  it  exists.  This  puts 
the  consumer  in  a  quandary  since  a  decision  must  be  made  based  on  terminology  that  has 
different  meanings  depending  on  who  wrote  it  to  select  from  very  different  available 
OODBMSs  that  may  be  very  costly.  Since  each  OODBMS  is  so  different  and  the  computer 
software  industry  is  so  volatile,  the  consumer  may  lose  all  support  and  have  to  turn  to 
entirely  new  system  if  the  company  that  produced  his  system  goes  under.  Clearly,  if 
OODBMSs  had  a  consistent  terminology  and  definition,  then  it  would  be  much  more 
widely  accepted. 

3.     Relational  Operations 

Companies  that  produce  OODBMSs  generally  think  in  terms  of  managing  objects 
and  not  relations  with  their  database.  Thus,  there  are  not  any  commercial  OODBMSs  that 

support  relations  and  relational  operations  .  However,  an  OODBMS  that  does  support 


3.  Some  do  support  an  object-SQL  interface. 
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relational  operations  would  be  valuable  in  terms  of  increased  compatibility  and 
completeness.  It  has  been  shown  that  relational  operations  can  and  should  be  made  a  part 
of  an  object-oriented  database  [Fi92][Ne88][NMO90].  An  OODBMS  that  incorporates 
these  operations  would  benefit  from  increased  credibility  along  with  acceptability  among 
relational  database  developers. 

4.     Other  Problems 

Other  problem  areas  that  cannot  be  overlooked  include  the  inability  for  most 
commercial  OODBMSs  to  interface  with  relational  systems  [St91a].  A  better  solution  is  the 
integration  of  both  object-oriented  and  relational  systems.  However,  in  the  absence  of  an 
integrated  approach,  some  interface  should  be  available.  Finally,  along  with  the  powerful 
modeling  capabilities  of  the  object-oriented  data  model  comes  an  increased  difficulty  in 
making  changes  to  the  database  as  requirements  change  in  addition  to  design  difficulties 
[Ed91]. 

D.     A  COMBINED  SYSTEM 

1.     Desirable  Properties 

A  combined  relational/object-oriented  system  will  eliminate  limitations  that  each 
of  these  systems  possess  as  a  system  by  itself.  It  would  allow  a  relationally  modeled  system 
to  naturally  model  and  define  complex  objects  along  with  their  behavior  which  would 
facilitate  better  performance  in  complex  applications.  This  ability  is  not  found  in  simple 
extended  relational  systems.  Generally,  they  allow  for  the  definition  of  complex  objects  but 
not  for  their  behavior. 

Relational  classes  as  part  of  a  combined  systems  class  library  are  needed: 
database,  relation,  and  tuple  (or  record)  classes.  Additionally,  the  five  fundamental 
relational  algebra  operations  (select,  project,  Cartesian  product,  difference,  and  union) 
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should  be  a  part  of  all  OODBMSs.  Credibility  and  standardization  of  combined  systems 
will  be  enhanced  as  a  result. 

2.     Possible  Approaches 

Two  primary  approaches  to  a  combined  relational/object-oriented  system  exist. 
The  first  is  to  take  an  existing  RDBMS  and  extend  the  system  to  include  all  of  the  concepts 
in  the  object-oriented  paradigm.  Once  this  has  been  done,  the  underlying  system  is  still 
relational  so  the  system  should  still  have  all  of  the  functionality  of  a  purely  relational 
system  along  with  the  advantages  of  the  object-oriented  paradigm.  This  would  be  a  difficult 
and  arduous  task.  Additionally,  since  the  underlying  system  is  relational,  it  may  not  be  as 
efficient  as  an  object-oriented  system  at  managing  objects.  The  other  approach  is  to  take  an 
existing  OODBMS  system  and  construct  classes  and  associated  methods  that  would  allow 
the  OODBMS  to  provide  relational  functionality  within  the  system.  Thus,  the  relational 
model  could  be  used  with  this  system.  This  approach  is  much  simpler  since  it  requires  the 
construction  of  three  classes  and  their  associated  methods  as  compared  with  trying  to 
implement  all  of  the  complex  and  powerful  concepts  of  the  object-oriented  paradigm. 

E.     WHY  THIS  APPROACH 

"The  relational  model  is  a  viable  approach  to  organizing  persistent  objects  in  an 
object-oriented  database"  [NMO90,  p.  319].  The  real  world  consists  of  complex  entities/ 
objects  that  are  easily  modeled  with  an  object-oriented  paradigm.  A  R/OODBMS  exists 
with  the  best  of  both  worlds;  it  reduces  the  limitations  that  the  individual  systems  realize 
by  themselves.  Conventional  applications  in  a  R/OODBMS  can  be  extended  to  include 
complex  data,  and  new  non-conventional  applications  may  also  be  developed  in  the  same 
system. 

Original  work  done  in  the  development  of  the  ROOMS  paradigm  [Ne88]  and  later 
work  done  with  a  R/OODBMS  as  implemented  in  Prograph  [Fi92]  is  extended  in  this 
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thesis.  ROOMS  was  not  a  full  R/OODBMS  since  it  lacked  the  ability  to  store  persistent 
objects.  A  R/OODBMS  in  Prograph  was  a  logical  next  step  in  the  extension  of  ROOMS  to 

a  full  database  system.4  This  work  completes  the  proof  of  concept  that  began  with  ROOMS 
and  culminates  in  its  extension  into  a  commercially  available  OODBMS,  IDB.  The  system 
implemented  in  this  thesis  is  a  single  R/OODBMS  that  can  fulfill  the  requirements  of  both 
relational  and  object-oriented  users. 


4.  This  is  because  Prograph  is  an  object-oriented  programming  language  that  supports  the  storage 
and  retrieval  of  persistent  objects  in  secondary  storage  through  its  built-in  database  primitives 

[Fi92]. 
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IV.  IMPLEMENTATION  OF  AN  R/OODBMS  IN  IDB 

An  R/OODBMS  in  IDB,  as  implemented  in  this  thesis,  is  the  culmination  of  a  proof 
of  concept  that  began  with  ROOMS  [Ne88].  In  that  respect,  it  is  not  intended  to  be  a 
production/commercial  system.  This  chapter  describes  the  fundamental  design  and  detail 
of  the  implementation  of  an  R/OODBMS  in  IDB.  Although,  there  may  be  'better'  or  more 
efficient  implementations,  the  system  as  described  is  functional  and  does  provide  a  proof 
of  concept.  It  should  also  be  noted  that  the  author  has  worked  exclusively  with  the 
commercially  available  IDB  system.  That  is,  there  were  no  special/trade  tools  provided  by 
Persistent  Data  Systems  for  this  effort. 

A.     THE  SYSTEM  DESIGN 

As  described  in  [Ne88],  the  fundamental  design  of  ROOMS  is  quite  simple.  This 
thesis  is  modeled  after  that  design.  A  database  is  comprised  of  a  group  of  relations.  A 
relation  is  comprised  of  a  group  of  tuples.  A  tuple  is  comprised  of  a  group  of  attributes. 
Database,  relation,  and  tuples  are  all  implemented  as  classes.  Both  database  and  relation 

classes  are  IDB  node  class  types  while  the  tuple  class  is  a  strict  class  type.  Thus,  tuples 
have  as  descendents  user-defined  classes  that,  when  instantiated,  become  the  tuples 
comprising  a  relation.  In  this  manner,  relations  differ  by  the  type  of  tuples  they  contain. 

While  it  is  possible  to  create  stand-alone  applications  in  IDB,  the  R/OODBMS  was 
created  for  use  within  the  IDB  browser.  Thus,  the  IDB  core,  display,  and  browser  interface 
were  used  in  the  implementation  of  the  R/OODBMS.  The  R/OODBMS  user  interacts  with 


1.  Recall  that  in  IDB  a  strict  class  type  has  one  or  more  descendents  while  a  node  class  type  has  no 
descendents. 
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the  IDB  browser  to  view  the  relations  of  a  particular  database  and  to  perform  relational 

algebra  operations  on  relations  within  a  particular  database. 

Figure  17  shows  a  picture  of  the  IDB  Browser  Interface.  Pull  down  menus  are  listed 
along  the  top  of  the  window.  Within  the  browser,  the  programmer/application  developer 
may  introduce  their  own  menus.  We  opted  not  to  use  this  feature;  instead  the  commands 

that  the  R/OODBMS  user  needs  are  displayed  in  the  Menus  pane. 


El  IDB  Browser  g|§ 

13  1 

Cluster  Vieu  Options  Connands  Current  Context  Heap  Help 

horrent  s:$£3©ei* 

Address  Database 
Missionary/Cannibal  Database 

imsmmsaomm 

Relational  Hddress  DB2 





" Browser  State 

=>  dbdir:dbdir  CE]  /Hone 

root  :  linked  seq  =>  [Hddress  Database,..*] 
current  ;  linked  seq  =>  [Address  Database,...] 
context  :  nil  =>  nil 

""tteeus 

Current  First 
Last 

Help:  sequence  elenent 

Error; 

nornal  > 

Figure  17  IDB  Browser  Interface 


2.  A  database  directory  was  developed  to  allow  the  R/OODBMS  to  manage  more  than  one  database. 
APPENDIX  B  contains  the  source  code,  the  IDL  schema  and  C  implementation  of  the  methods  for 
the  database  directory  cluster.  APPENDIX  C  contains  the  IDL  schema  and  C  method  implementa- 
tions for  R/OODBMS. 

3.  There  are  four  panes  within  the  browser  window  as  shown  in  Figure  17:  Current  Object,  Context 
Object,  Browser  State,  and  Menus.  The  user  may  have  none,  all,  or  any  combination  of  these  panes 
displayed  at  any  time  by  making  appropriate  menu  selections  from  the  View  menu  commands. 
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Since  the  R/OODBMS  is  implemented  as  a  proof  of  concept,  it  is  not  designed  to  have 
all  of  the  facilities  that  are  expected  in  a  production  system.  Therefore,  several  assumptions 
are  made  about  the  R/OODBMS.  It  is  assumed  that  the  user  will  input  correct  information, 
in  the  correct  syntax,  for  the  R/OODBMS  relational  algebra  operations  and  that  the 
relations  named  as  operands  in  the  operation  actually  exist  within  the  database. 
Additionally,  all  tuples  within  a  relation  must  be  instances  of  the  same  tuple  descendent 
class.  Thus,  error  checking  is  not  provided  consistently  in  all  relational  algebra  operations. 
That  is,  different  amounts  of  error  checking  have  been  provided  among  the  operations  in 
the  hope  of  demonstrating  the  feasibility  of  detailed  error  checking  without  the  overhead  of 
implementing  it  for  every  operation.  In  two  cases,  detailed  error  checking  has  been 
implemented  to  demonstrate  the  feasibility  of  doing  it  for  all  operations,  as  will  be 
described  shortly. 

By  the  same  token,  the  relational  operations,  as  implemented  in  this  thesis,  are 
implemented  in  the  simplest  manner  possible  while  still  demonstrating  the  feasibility/proof 
of  concept  of  a  R/OODBMS.  For  example,  you  may  recall  from  Chapter  II  that  the 
selection  condition  of  a  selection  operation  is  a  boolean  expression  consisting  of  clauses  of 
the  form: 

<name  of  attributexcomparison  operatorxconstant  value>; 

or 

<name  of  attributexcomparison  operatorxname  of  attribute> 
where  <name  of  attributo  is  the  name  of  an  attribute  of  the  input  parameter  relation; 
<comparison  operator>  is  either  =,  <,  <,  >,  >,  or  ^;  and  <constant  value>  is  any  arbitrary 
number  of  clauses  may  be  connected  with  the  AND,  OR,  and  NOT  operators  to  form  the 
selection  condition  expression  [EN89].  In  this  implementation  of  R/OODBMS,  only  one 
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clause  is  allowed  for  the  selection  condition  since  allowing  an  arbitrary  number  of  clauses 
is  just  repeated  applications  of  one  clause  in  its  simplest  form. 

B.      ORIENTATION  TO  R/OODBMS 

This  section  is  intended  to  familiarize  the  reader  with  using  the  R/OODBMS.  It  is  not 
intended  to  be  a  complete  user's  guide.  However,  it  should  provide  sufficient  information 
so  that  a  user  could  use  the  source  code  in  APPENDIX  B  and  APPENDDC  C  on  a  platform 
supported  by  IDB,  translate  the  IDL  schema,  compile,  and  run  the  R/OODBMS. 

1.     The  Database  Directory 

The  database  directory  allows  multiple  R/OODBMS  databases  to  be  managed  in 
IDB.  If  IDB  is  run  with  the  following  command  line  entry,  then  IDB  will  open  the  database 
directory  cluster  and  display  the  browser  window  shown  in  Figure  17:  'idb  -c  dbdir  -t 

dbdir  .  In  Figure  17,  there  are  four  databases  in  the  directory:  Address  Database, 
Missionary/Cannibal  Database,  Relational  Address  DB,  and  Relational  Address  DB2.  If 
one  of  the  databases  is  selected,  say  the  Relational  Address  DB,  then  the  browser  window 
would  appear  as  shown  in  Figure  18.  Here  the  Relational  Address  DB  object  is  the  current 
object  and  the  directory  (sequence)  of  databases  becomes  the  context  object.  To  enter  this 
database,  select  the  enter  command  from  the  Menus  pane. 


4.  Of  course,  there  are  more  efficient  methods  of  implementation  than  just  repeated  applications. 

5.  The  name  following  the  -c  flag  (dbdir  in  this  case)  in  the  command  indicates  the  home  cluster  that 
will  be  used  when  IDB  begins  running.  The  name  following  the  -t  flag  (dbdir)  indicates  the  home 
cluster  type.  In  this  case,  the  home  cluster  is  dbdir.c  and  its  type  is  dbdir. 
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Figure  18  Entering  a  Database 

2.     Inside  a  R/OODBMS  Database 

Entering  the  Relational  Address  DB  database,  IDB  opens  the  database  cluster  and 
displays  the  relations  within  the  database  in  the  Current  Object  pane  as  shown  in  Figure 

19.  Now,  any  of  the  relations  can  be  opened.  For  example,  if  the  ptl  relation  is  selected 
then  the  Context  Object  pane  will  display  the  list  of  all  relations  within  the  database  and  the 
Current  Object  pane  will  display  short  form  of  the  tuples  within  the  relation  ptl  (see  Figure 
20).  Since  each  tuple  within  a  relation  is  also  an  object,  a  tuple  can  be  selected  in  which 


6.  In  the  interest  of  saving  space  and  enhancing  readability,  interesting  panes  only  will  be  shown  in 
Figures. 
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case  the  list  of  tuples  would  move  to  the  Context  Object  pane  and  the  particular  tuple 
selected  is  displayed  in  the  Current  Object  pane. 
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Figure  19  The  Relational  Address  DB 

Notice  that  as  different  objects  are  displayed  in  the  Current  and  Context  Object 
panes,  the  commands  available  in  the  Menus  pane  change.  At  any  time,  the  Menus  pane 
will  display  those  methods  associated  with  the  objects  being  displayed  in  either  of  the 
object  panes  as  long  as  the  application  programmer  has  specified  them  to  be  browser 
visible;  there  may  be  methods  that  are  required  by  an  object  for  interaction  with  other 
objects  only  that  the  application  programmer  decides  the  application  user  should  not  have 
access  to  (i.e.,  they  are  not  browser  visible). 
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Figure  20  The  Relation  ptl 

When  any  of  the  relations  within  a  database  is  displayed  in  the  Current  Object 
pane,  the  Menu  pane  commands  associated  with  the  Current  Object  include  the  five 
fundamental  relational  algebra  operations  that  are  implemented  within  the  R/OODBMS. 
Selecting  any  of  the  relational  algebra  operations  brings  up  an  associated  pop-up  window 
that  allows  the  particular  operation  to  be  expressed  in  a  query.  The  details  of  each  of  the 
relational  algebra  operations  are  discussed  in  the  next  section. 
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C.     RELATIONAL  METHODS 

As  discussed  in  Chapter  II,  there  are  five  fundamental  relational  algebra  operations 
from  which  all  other  relational  algebra  operations  can  be  constructed:  union,  difference, 
selection,  Cartesian  product,  and  projection.  These  five  operations  are  implemented  as 
methods  for  the  node  class  relation  in  the  R/OODBMS.  The  difficulty  in  implementing 
these  operations  is  directly  related  to  the  structure  of  the  resultant  relation  as  compared  to 
that  of  the  operand  relation(s). 

With  the  union,  difference,  and  selection  operations,  the  resultant  relation  has  the 
same  structure  as  the  operand  relation(s).  Thus,  the  resultant  relation's  structure  is  already 
defined  within  the  database  and  can  be  used  to  construct  the  resultant  relation.  In  this  sense, 
these  operations  may  be  considered  simple.  Cartesian  product  and  projection,  on  the  other 
hand,  both  yield  resultant  relations  that  have  a  different  structure  from  the  operand 
relation(s).  Thus,  the  resultant  relation's  structure  may  not  already  exist  within  the  database 
and  either  must  be  explicitly  defined  in  the  schema  or  dynamically  constructed  at  run-time. 
Thus,  these  two  operations  may  be  considered  difficult. 

The  details  of  each  operation  are  discussed  below  along  with  difficulties  encountered 
in  their  implementation  and  special  implementation  notes.  Once  one  of  the  simple 
operations  (i.e.,  result  relation  has  the  same  structure  as  the  operand)  was  completed,  the 
other  simple  operations  followed  relatively  quickly  in  their  implementation.  Selection, 
however,  was  more  difficult  than  the  other  two  since  it  required  the  implementation  of 

default  comparison  operations:  equal  to,  less  than,  and  greater  than. 


7.  As  discussed  in  Chapter  II,  there  are  six  comparison  operators:  =,  ^,  <,  >,  <,  and  >.  The  last 
two  are  a  combination  of  =  and  <  and  =  and  >,  respectively.  ^  is  just  the  inverse  of  =.  Thus,  it  is 
sufficient  to  implement  only  =.  <,  and  >. 
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Before  continuing,  it  is  important  to  discuss  the  two  possibilities  for  inserting  tuples 
into  the  resultant  relations:  (1)  a  new  tuple  object  can  be  created  and  then  the  values  of  the 
tuple  can  be  copied  into  this  new  tuple,  or  (2)  a  reference  to  the  tuple  to  be  inserted  can  be 

used.8  If  the  first  approach  is  used,  then  the  relations  are  independent  of  each  other.  That 
is,  an  update  to  any  of  the  relations  (operand  or  resultant)  will  have  no  effect  on  the  other 
relations. 

In  the  second  approach,  the  relations  become  interdependent  since  they  reference  the 
same  tuple  relation.  Thus,  a  change  to  the  tuple  in  one  relation  will  also  be  reflected  in  the 
corresponding  referenced  tuple  in  the  other.  This  may  or  may  not  be  desirable.  A  problem 
associated  with  this  approach  is  the  resolution  between  duplicate  tuples  in  a  binary 
operation.  For  example,  there  are  two  relations  A  and  B,  and  we  would  like  to  perform  the 
union  operation.  Relation  A  contains  a  tuple  that  is  identical  to  one  in  B.  Thus,  it  is  a 
duplicate  and  must  not  be  duplicated  in  the  resultant  relation,  call  it  C.  But,  which  tuple 
does  C  reference:  the  tuple  in  A  or  the  tuple  in  B?  They  are  both  identical. 

It  would  be  best  to  allow  the  user  to  indicate  in  their  query  which  of  the  two 
approaches  is  desired  for  a  particular  query.  To  show  the  feasibility  of  both  approaches, 
some  operations  in  the  R/OODBMS  were  implemented  using  the  reference  approach  while 
others  used  the  copy  approach.  However,  no  operation  was  implemented  with  both 
approaches  left  for  the  user  to  choose  from.  It  is  clear,  however,  that  if  they  can  be 
implemented  separately,  then  it  is  just  a  matter  of  additional  programming  and  fine-tuning 
the  user  interface  to  add  the  ability  to  let  the  user  choose. 

The  persistence  of  the  resultant  relation  for  these  operations  should  also  be 
considered.  The  resultant  relation  is  not  initially  written  to  the  database  in  secondary 


8.  That  is,  either  make  a  copy  of  attributes  in  existing  tuples  or  provide  pointers  to  them. 
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storage,  although  it  does  appear  in  the  list  of  relations  for  the  database  in  the  browser 
window  (it  only  exists  in  main  memory).  If  a  write  transaction  is  entered  and  committed, 
then  the  resultant  relation  will  be  written  to  secondary  storage.  If  a  write  transaction  is  not 
entered  and  subsequently  committed,  then  the  resultant  relation  is  lost  when  the  transaction 
on  the  database  is  closed.  Additionally,  if  a  write  transaction  is  entered  and  subsequently 
aborted,  then  the  database  cluster  is  read  from  disk  again  and  any  relation  not  previously 

stored  on  secondary  storage  is  lost. 

Although  a  resultant  relation  only  exists  in  main  memory,  it  may  be  used  in  other 
queries  just  as  any  other  relation  within  the  database.  It  does  not  matter  whether  the 
temporary  resultant  relation  has  been  committed  to  secondary  storage,  as  far  as  the 
relational  algebra  operations  are  concerned  -  the  resultant  relations  may  be  operated  on  as 
any  other  relation.  For  example,  if  relation  Rl  were  unioned  with  R2  and  the  resultant 
relation  TEMP_R3  were  yielded,  then  a  subsequent  difference  operation  could  be  executed 
using  TEMP_R3.  It  should  be  remembered,  however,  that  even  though  these  relations  may 
be  used  in  other  queries,  they  are  not  written  to  secondary  storage  until  a  write  transaction 

has  been  entered  and  subsequently  committed. 

We  will  now  discuss  each  of  the  5  basic  operations  individually. 

1.     Union 

The  union  operation  is  performed  by  the  function  union_op.  It  takes  two  relations, 
Rl  and  R2,  and  computes  their  union.  The  resultant  relation  is  created  by  the  function 


9.  Naturally,  if  a  query  is  made  during  a  write  transaction,  then  the  persistence  of  the  resultant  rela- 
tion depends  solely  upon  whether  the  write  transaction  is  aborted  or  committed. 

10.  All  resultant  relations  will  be  saved  when  the  commit  is  executed.  By  the  same  token,  if  the  write 
transaction  is  aborted  then  all  of  the  resultant  relations  will  be  lost  since  a  new  transaction  is  entered 
after  the  abort  which  causes  the  database  to  be  read  from  secondary  storage. 
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init_temp_rel  which  takes  Rl  and  R2  as  its  parameters  and  returns  a  relation  with  a  unique 
name  and  some  default  values  taken  from  Rl.  The  syntax  of  the  union  operation  (shown  in 
the  center  of  the  pop-up  window  within  the  parentheses)  is  shown  in  Figure  21.  Notice  that 
there  is  no  resultant  relation  listed  in  the  query.  This  operation  creates  and  names  a  resultant 
relation  that  will  appear  in  the  list  of  relations  for  the  current  database  (this  is  in  contrast  to 
the  project  and  Cartesian  product  operations  where  the  resultant  relation  is  named  in  the 
query,  as  will  be  discussed  shortly).  As  previously  noted,  it  would  be  desirable,  in  a 
production  system,  to  have  the  ability  to  phrase  a  query  with  the  option  of  providing  a 
relation  name  or  having  a  default  name  generated. 
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The  union  operation,  in  contrast  to  the  other  operations11,  has  extensive  error 
checking  in  its  implementation.  The  R/OODBMS  first  checks  to  make  sure  that  the  operand 
relations  exist  within  the  database.  If  both  relations  are  found  in  the  database,  then  they  are 
checked  for  union  compatibility.  Provided  that  the  relations  exist  and  are  compatible,  a 
temporary  relation  is  created  by  the  init_temp_rel  function  and  subsequently  its  tuples  are 
inserted,  ensuring  no  duplicate  tuples.  Tuples  are  inserted  by  reference  and  in  the  case  of 
inserting  a  duplicate  tuple,  a  reference  is  made  to  the  tuple  from  relation  Rl. 

The  function  used  to  check  for  duplicate  tuples  is  the  equal_to  method  which  is 
defined  for  the  class  tuple.  As  such,  it  has  a  default  implementation  that  only  checks  to  see 
if  the  tuples  reference  the  same  object.  This  method  will  most  likely  have  an  over-riding 
user- supplied  implementation  for  each  tuple  type.  The  prototype/signature  for  the  method 

19 

is  boolean  equal_to(tuple,  tuple,  index)  .  That  is,  the  function  takes  three  parameters,  two 
tuples  and  an  index,  and  returns  a  boolean.  Each  of  the  tuples  must  be  of  the  same  type. 
When  the  value  of  the  index  is  0,  then  the  equal_to  function  compares  the  each  entire  tuple, 
all  the  attribute  values.  Otherwise,  index  is  greater  than  zero  and  is  an  index  to  the  attribute 
within  the  tuples  that  is  to  be  compared  (selection  operation).  This  function  is  also  used  in 
the  selection  operation. 

2.     Difference 

The  difference  operation  is  implemented  in  a  manner  similar  to  that  of  the  union 
operation.  The  function  set_diff_op  takes  two  relations  and  computes  their  difference.  The 
resultant  relation  is  created  in  exactly  the  same  manner  as  in  union_op.  Set_diff_op  also  has 


11.  The  difference  operation  has  the  same  level  of  error  checking  as  the  union  operation. 

12.  This  is  the  actual  C  function  signature/prototype  that  shows  the  function  equal_to  has  three  pa- 
rameters (tuple,  tuple,  and  index)  and  returns  a  boolean  to  the  caller  of  the  function. 
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the  same  level  of  error  checking  as  union_op.  The  main  difference  between  its 
implementation  and  that  of  union_op  is  in  the  insert  decision  for  tuples  that  will  comprise 
the  resultant  relation. 

In  the  union_op  function,  all  of  the  tuples  from  Rl  are  inserted  into  the  resultant 
relation.  Afterwards,  the  tuples  from  Rl  are  compared  with  those  already  in  the  resultant 
relation  and  if  they  are  not  duplicates,  then  the  tuple  from  R2  is  inserted  into  the  resultant 
relation.  In  the  set_diff_op,  each  tuple  in  Rl  is  checked  to  see  if  it  exists  in  R2;  if  it  does 
not,  then  the  tuple  is  inserted  into  the  resultant  relation.  Insertion  is  by  reference  here  as  in 
the  union_op  function.  Figure  22  shows  the  difference  query  pop-up  window  with  the 
correct  syntax  for  the  query. 
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Figure  22  Difference  Query 
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3.     Selection 

Of  the  three  simple  operations,  selection  was  the  most  difficult  to  implement.  It  is 
a  more  complex  operation  since,  even  in  its  simplest  form,  it  operates  on  a  single  attribute 
of  a  relation  (which  can  be  any  one  of  the  attributes  in  the  relation's  schema)  and  compares 
the  value  of  that  attribute  for  every  tuple  in  the  relation  with  a  specified  value  to  determine 
which  tuples  should  be  included  in  the  resultant  relation.  Again,  the  resultant  relation  is 
created  using  the  function  init_temp_rel.  This  implementation,  select_op,  has  the 
functionality  necessary  to  demonstrate  the  feasibility  of  implementing  a  fully  functional 
selection  operation. 

The  general  syntax  for  the  R/OODBMS  selection  operation  is: 
<relation  name>  select  <attribute  name>  comparison  operator>  <attribute  value> 
where  <relation  name>  is  the  name  of  the  relation  to  be  operated  on,  <attribute  name>  is 
the  name  of  the  attribute  within  the  relation  upon  which  selection  will  be  based, 
comparison  operator>  is  a  user-defined  comparison  operator  (equal_to,  greater_than,  or 
less_than),  and  <attribute  value>  is  the  value  to  be  compared  with.  Figure  23  shows  the 
select  query  syntax.  The  particular  query  listed  selects  all  tuples  of  ptl  where  the  attribute 
value  of  Hours  Worked  is  greater  than  the  Hours  Worked  attribute  in  Comp  Object. 


68 


IB  Browser 

,er  Vieu  Options  Connands  Current  Context  Heap  Help 

mmmmmmim 

wmmmmmm 

ip  obj 
550926 

Please  input  the  Select  query   <R1  select  attr  conp.op  object): 

Help:  connand  input  line 
Error: 

s  OB 

n 

e 
Product 

on 

■IM^iMj     **>tl  select  Hours  Uorked  >  Conp  Ob  iectH 

II 

1 

♦ 

:tion  > 

Figure  23  Select  Query 

It  would  be  desirable  to  be  able  to  list  just  a  value  for  the  <attribute  value>; 
however,  at  a  minimum  it  is  necessary  to  be  able  to  compare  the  same  attributes  of  two 
objects.  In  R/OODBMS,  the  <attribute  value>  is  a  comparison  object  of  the  same  type  as 
the  operand  relation,  Rl.  This  comparison  object  can  only  have  one  tuple  in  it  and  may  must 
have  at  least  one  of  the  attribute  values  entered,  the  one  to  be  used  for  comparison.  In  Figure 
23,  Comp  Object  has  the  same  type  as  ptl,  thus  it  has  the  same  attributes.  The  one  tuple  in 
Comp  Object  has  20  as  the  value  for  Hours  Worked.  Thus,  the  query  is  equivalent  to  select 
all  tuples  in  ptl  where  Hours  Worked  is  greater  than  20. 

Select_op  checks  the  database  to  ensure  that  both  the  relation  to  be  operated  on 
and  the  comparison  object  are  both  in  the  system.  If  they  are,  then  the  attribute  name  is  used 
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to  determine  the  index  into  the  relation  schema.  If  either  of  these  conditions  is  not  met,  then 
the  system  brings  up  a  pop-up  window  explaining  that  an  error  has  occurred,  what  the  error 
is,  and  allows  the  user  to  continue  without  crashing.  Again,  init_temp_rel  is  used  to  create 
and  name  the  resultant  relation  for  this  operation.  Finally,  based  on  the  comparison  operator 
specified  in  the  query,  the  appropriate  comparison  method  is  executed.  The  tuples  of  the 
operand  relation  are  iterated  through  and  those  meeting  selection  criteria  are  inserted  into 
the  resultant  relation  by  reference. 

4.     Cartesian  Product 

'Of  the  two  more  difficult  operations,  Cartesian  product  is  the  simpler  to 

implement  as  it  operates  on  all  attributes  of  the  tuples  in  each  of  the  operand  relations. 
Since  the  resultant  relation  has  a  different  structure  than  either  of  the  operand  relations,  the 
init_temp_rel  function  cannot  be  used.  Instead,  the  user  must  provide  the  definition  of  the 
resultant  relation  within  the  database  IDL  schema  beforehand.  Now,  a  relation  can  be 
created  within  the  database  to  hold  the  result  of  the  operation.  As  a  logical  consequence, 
the  relation  that  is  to  hold  the  result  of  the  operation  must  be  named  in  the  query.  Figure  24 
shows  the  Cartesian  product  query  pop-up  window  with  the  required  syntax. 


13.  This  is  in  contrast  to  the  project  operation  where  only  a  subset  of  the  attributes  will  end  up  in  the 
resultant  relation.  In  a  Cartesian  product  operation  all  of  the  attributes  from  each  operand  relation 
will  be  in  the  resultant  relation. 
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Figure  24  Cartesian  Product  Query 

Defining  the  resultant  relation's  IDL  schema  is  not  difficult  since  we  know  that 
its  schema  is  simply  the  concatenation  of  the  two  operand  relation's  schemas.  No  matter 
how  complex  the  two  operand  relation's  schemas  are,  the  Cartesian  product  resultant 

relation  will  simple  include  the  attributes  as  defined  in  both  of  the  operand  relations.  For 
example,  suppose  there  are  two  relations,  Employee  and  Assigned  Project,  with  their 
respective  tuple  types  defined  with  the  IDL  schema  shown  in  Figure  25. 


14.  If  multiple  inheritance  were  available,  the  resultant  relation  could  simply  be  defined  as  a  subclass 
of  each  of  the  operand  relations.  As  such,  it  would  inherit  the  attributes  of  each  of  superclasses. 
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emp_tuple  => 

person 

person, 

address 

addr, 

phone 

phone_number, 

widget 

idl_univ; 

proj_tuple  => 

essn 

integer, 

proj_num 

integer, 

hours 

rational; 

Figure  25  IDL  Schema  for  Employee  and  Assigned  Project  Relations 

In  our  example,  the  attribute  types  of  each  of  the  tuples  in  the  Assigned  Project 
relation  are  simple:  integers  and  rational.  However,  in  tuples  in  the  Employee  relation, 
attributes  have  user  defined  (and  provided)  types  and  are,  therefore,  more  complex.  But,  it 
is  still  a  simple  matter  to  create  the  schema  for  the  resultant  relation  for  a  Cartesian  product 
operation  since  all  of  the  types  (person,  addr,  phone_number,  idl_univ,  integer,  and 
rational)  are  already  defined  within  the  database  IDL  schema  (see  Figure  26). 


cartl 

_result_tuple  => 

person 

person, 

address 

addr, 

phone 

phone_number , 

widget 

idl_univ, 

essn 

integer, 

pro]_num 

integer, 

hours 

rational ; 

Figure  26  Example  Resultant  Relation  Schema  for  a  Cartesian  Product  Operation 

Cart_prod_op  implements  the  Cartesian  product  operation  by  first  determining  if 
the  two  operand  relations  and  the  resultant  relation  are  in  the  database.  If  they  do  exist,  then 
it  is  a  fairly  simple  matter  to  take  one  tuple  at  a  time  from  the  first  operand  relation, 
concatenate  it  with  each  tuple  of  the  second,  and  insert  each  resultant  tuple  into  the  resultant 
relation.  The  function  insert_tuples  is  used  by  cart_prod_op  to  insert  the  tuples  into  the 
resultant  relation. 
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In  the  query  shown  in  Figure  24,  r3  is  a  relation  with  emp_tuple  type  tuples,  ptl 
has  proj_tuple  type  tuples,  and  Cart  Resultl  has  cartl_result_tuple  type.  Figure  27  shows 
the  relation  r3  with  its  two  tuples,  Kelly  and  Spear.  In  the  left  side  of  Figure  27,  all  of  r3's 

tuples  are  shown  in  their  abbreviated  form.     In  the  right  side,  a  single  tuple  is  shown  in  its 
entirety. 


=>  Ronald  L.  3S33  <29  Dec  62>   [Karin] 
SSM:   120926190 

=>  (408)375-8619 

=>  397B  Ricketts  Road 

Honterey,   Cfl 

93940 

m 

=>         Kelly 
=>  Spear 

The  Relation  r3 

The  Spear  tuple  of  relation  r3 

Figure  27  The  Relation  r3  and  One  of  its  Tuples 

The  relation  ptl  is  less  complex  and  as  such  its  abbreviated  version  has  all  of  the 
information  of  each  tuple.  Therefore,  there  is  no  need  to  include  a  single  tuple  of  ptl  in  the 
Figure  28.  If  a  single  tuple  were  shown,  there  would  be  three  values:  an  employee  ssn, 
project  number,  and  hours  worked.  However,  these  values  would  then  be  listed  sequentially 
in  a  vertical  fashion. 


15.  The  abbreviated  form  only  shows  the  last  name  of  the  person  attribute.  The  predefined  IDB  func- 
tions idl_print  and  idl_key  can  have  their  implementations  over-ridden  by  the  user  to  present  the  re- 
lation and  its  separate  tuples  in  any  desired  fashion.  Figure  27  shows  one  such  display. 
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Figure  28  The  Relation  ptl 

The  result  of  the  Cartesian  product  of  relations  r3  and  ptl  is  shown  in  Figure  29. 
The  left  side  of  the  figure  shows  the  abbreviated  display  of  the  relation  Cart  Result  1  tuples, 
while  the  other  side  shows  one  entire  tuple  from  the  relation. 
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93940 
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The  Relation  Cart  Result  1 


The  Spear  tuple  of  Cart  Result  1 


Figure  29  Cartesian  Product  of  r3  and  ptl 

5.     Projection 

Although  the  projection  operation  has  a  resultant  relation  with  the  same  number 
of  tuples  as  the  operand  relation,  it  is  complicated  by  the  fact  that  any  combination  of  the 
attributes  of  the  operand  relation  can  constitute  the  schema  of  the  resultant  relation.  As  with 
Cartesian  product,  since  the  resultant  relation  has  a  different  structure  than  that  of  the 
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operand  relation,  the  user  must  provide  the  definition  for  the  resultant  relation  in  the  IDL 
schema  beforehand.  Again,  this  is  not  a  difficult  task  since  the  schema  of  the  resultant 
relation  is  a  subset  of  the  attributes  of  the  operand  relation.  Thus,  all  of  the  attribute  types 
must  already  be  defined  in  the  database  schema.  Parsing  the  query  is  more  difficult  since 
any  combination  of  the  attributes  can  be  specified  in  the  query  to  be  projected  into  the 
resultant  relation.  Figure  30  shows  the  browser  pop-up  window  that  accepts  the  project 
query  and  also  specifies  the  query  syntax  for  this  operation. 
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Figure  30  Project  Query 

Consider  a  relation  with  tuples  of  type  proj_tuple  as  defined  in  Figure  25.  If  the 
user  wanted  to  project  the  hours  worked  and  employee  ssn  of  each  tuple,  then  a  schema  for 
the  resultant  relation  would  look  like  the  one  in  Figure  31.  The  function  project_op 
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implements  the  operation.  Once  it  has  checked  to  ensure  that  the  operand  relation  and  the 
resultant  relation  exist,  it  calls  the  function  insert_fields  to  insert  the  appropriate  attributes 
into  the  resultant  relation. 


projectl_result_tuple    =>  hours  :   rational, 

essn   :   integer; 


Figure  31  Example  Resultant  Relation  Schema  for  a  Project  Operation 

D.     THE  DATABASE  CLASS 

The  database  class  is  an  DDL  node  class  and  is  actually  quite  simple.  Its  sole  purpose 
is  to  keep  track  of  the  relations  within  the  database.  As  mentioned  in  Chapter  n,  each  IDB 
cluster  must  have  a  root  class  from  which  all  other  classes  can  be  reached.  For  the  R/ 
OODBMS,  the  database  class  is  the  root.  Thus,  all  functions  that  implement  the  relational 
algebra  operations  start  their  search  for  the  relations  from  this  class.  This  coincides  with  the 
idea  of  a  database  being  a  collection  of  relations. 

1.     Attributes 

The  database  class  has  only  two  attributes:  name  and  relations.  The  name  attribute 
is  included  so  that  when  a  database  is  entered  users  can  see  the  name  of  the  database  that 
they  are  in.  However,  none  of  the  operations  in  the  R/OODBMS  require  this  attribute.  The 
relations  attribute  is  very  important  since  it  is  the  means  by  which  all  relations  in  the 
database  are  reached.  Its  type  is  a  sequence  of  relations  where  relation  is  another  IDL  node 

class.  The  sequence  is  a  doubly-linked  list.16  All  of  the  R/OODBMS  relational  algebra 
operations  use  the  relations  attribute  to  iterate  through  when  trying  to  locate  a  particular 
relation  within  the  database. 
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2.     Methods 

As  with  all  objects  in  R/OODBMS,  the  predefined  IDB  core  interface  methods 

17 

idl_key  and  idl_print  are  over- written.  Simply  stated,  idl_print  displays  an  object  while 
idl_key  displays  a  short  description  of  the  object  [Pe91a].  Their  predefined 
implementations  are  functional  but,  of  course,  cannot  anticipate  the  types  of  objects  that 
will  be  displayed,  much  less  the  most  pleasing  format  to  display  them  in.  In  the  following 
discussion  of  other  classes  these  methods  will  not  be  discussed  again  although  each  has  its 
own  implementation  for  the  idl_key  and  idl_print  methods. 

The  only  other  method  defined  for  the  database  class  is  new_relation  which,  as 
the  name  implies,  creates  a  new  relation  and  inserts  it  into  the  database.  To  create  a  new 
relation  using  the  new_relation  method,  the  user  must  first  enter  a  write  transaction. 
Otherwise,  when  this  method  is  selected  from  the  Menus  pane,  an  initialize  new  relation 
pop-up  window  will  appear  but  the  user  will  not  be  able  to  view  and  edit  all  of  the  relation 
attributes  necessary.  If  a  write  transaction  is  open  when  new_relation  is  selected,  then  the 

pop-up  window  will  display  all  attributes  of  a  relation  ready  for  editing.  The  user  is 
responsible  for  initializing  the  relation  attributes  to  valid  values. 


16.  Sequences  in  IDB  are  either  arrays  (the  default)  or  doubly-linked  lists.  Arrays  are  convenient  for 
sequences  with  a  static  number  of  entries.  However,  every  time  the  size  of  the  sequences  changes 
there  is  a  great  amount  of  overhead  involved.  Linked  lists  support  sequences  whose  number  of  en- 
tries varies  dynamically. 

17.  Both  idl_key  and  idl_print  can  only  be  used  with  the  display  manager.  An  exception  will  be 
raised  if  attempts  are  made  to  invoke  these  methods  without  the  display  manager.  [Pe91a] 

18.  The  idl_print  implementations  for  relations  do  not  display  all  attributes  during  read  and  examine 
transactions.  However,  since  the  user  needs  the  ability  to  edit  all  attributes,  they  are  visible  during 
write  and  create  transactions. 
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E.      THE  RELATION  CLASS 

Codd's  relational  model  is  simple,  representing  databases  as  a  collection  of  relations 
(or  tables).  Hence,  relations  are  the  fundamental  building  block  of  the  model  and  as  such 
the  relation  class  of  our  R/OODBMS  is  the  fundamental  building  block  of  the  system.  As 
with  the  database  class,  the  relation  class  is  an  IDB  node  class  type.  Since  a  relation  is  a 
collection  of  tuples,  it  stands  to  reason  that  the  attribute  tuples  is  the  most  important 
attribute  in  this  class. 

1.     Attributes 

a.  Relation  name 

This  attribute  plays  a  greater  roll  in  the  R/OODBMS  than  does  the  database 
classes'  attribute  name.  The  relation_name  allows  different  relations  within  a  database  to 
be  easily  differentiated.  Of  course,  the  database  name  within  the  database  directory  plays 

as  great  a  role.  The  type  of  this  attribute  is  an  IDB  string. 

b.  Attributenames 

The  relational  schema  is  specified  by  the  relation's  attributes  which  are  listed 
in  attribute  names.  This  attribute  has  a  type  that  is  a  sequence  of  name  where  name  is  an 
object/class  (an  IDB  node  class)  that  has  a  single  attribute,  name.  The  name  attribute  of  the 
name  object  is  a  string  type.  Thus,  attribute_names  is  simply  a  sequence  of  strings.  Since 
the  schema  of  a  relation  is  static,  the  default  array  sequence  is  used  here. 


19.  An  IDB  string  differs  from  a  C  string  in  that  it  has  an  additional  null  character  at  the  end  of  the 
string.  That  is,  there  are  two  null  characters  at  the  end  of  an  IDB  string.  IDB  strings  can  generally  be 
used  in  the  same  manner  as  C  strings. 
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The  degree  of  a  relation  is  simply  determined  by  the  number  of  attributes. 
This  is  easily  done  by  checking  the  size  of  the  array  that  comprises  attribute_name.  Two 
relations  are  said  to  be  union  compatible  if  each  is  of  the  same  degree  and  if  corresponding 
attributes  have  common  domains.  Thus,  attribute_names  is  used  by  both  the  union  and 
difference  operations  to  determine  if  the  two  operand  relations  are  union  compatible. 

The  project  and  select  operations  are  the  only  other  R/OODBMS  relational 
algebra  operations  that  require  the  attribute  attribute_names  since  they  operate  on  a  subset 
of  the  attributes  and  single  attribute  of  the  operand  relation,  respectively.  Specifically, 
attribute_names  is  used  to  determine  if  an  attribute(s)  in  a  query  is  in  the  operand  relation 
or  not.  Additionally,  it  is  used  to  determine  the  index  (position  within  the  relational  schema) 
of  an  attribute. 

c.  Attribute_types 

Attribute_types  is  of  the  same  type  as  attribute_names,  however,  it  is  used 
only  in  support  of  the  union  and  difference  operations  to  determine  if  operand  relations  are 
union  compatible.  As  stated  above,  union  compatible  relations  have  corresponding 
attributes  with  a  common  domain.  Having  a  common  domain  means  that  the  attributes  have 
the  same  types.  Thus,  once  two  relations  are  determined  to  be  of  the  same  order,  their 
attribute  types  are  checked  to  ensure  that  they  have  a  common  domain. 

d.  Tuples 

The  tuples  attribute  within  a  relation  is  a  sequence  of  tuples  where  tuple  is  an 

20 

IDB  strict  class  type.  Thus,  tuple  has  subclasses  which  are  referenced  by  this  attribute. 
Thus,  IDB  allows  a  relation  to  have  a  sequence  of  tuples  where  some  of  the  tuples  reference 


20.  An  attribute  in  IDB  that  has  a  strict  class  type  can  reference  that  class  or  any  of  its  descendants. 
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one  subclass  type  of  the  IDB  strict  class  tuple  while  others  reference  a  different  subclass. 
However,  if  allowed  in  an  R/OODBMS,  then  this  sequence  of  tuples  should  not  be  called 
a  relation,  as  this  would  allow  various  tuples  to  have  a  different  number  of  attribute  values 
and/or  have  different  domains  for  corresponding  attributes.  Thus,  all  tuples  within  a 
relation  must  be  of  the  same  subclass  of  the  IDB  strict  class  tuple. 

It  is  the  tuples  attribute  that  allows  one  relation  to  differ  from  another  in 
structure.  All  of  the  descendents  of  the  IDB  strict  class  tuple  are  user  defined.  The  user  may 
define  a  subclass  of  tuple  to  have  any  desired  structure.  For  example,  the  user  may  with  to 
have  an  employee  relation  and  a  project  relation  where  the  employee  relation  contains 
personal  information  about  the  employee  while  the  project  relation  contains  information 
about  different  projects  that  the  company  has  worked  on.  A  relation  should  be  constructed 
to  model  each.  To  create  each  relation,  the  user  must  first  define  the  type  of  tuple  that  will 
comprise  each  relation:  an  employee  tuple  and  a  project  tuple.  Now,  the  new_relation 
method  of  the  database  class  is  used  to  create  the  new  relations.  Each  relation  should  be 
given  a  descriptive  name.  Only  employee  tuples  should  be  inserted  into  the  employee 
relation  and  project  tuples  into  the  project  relation.  This  restriction  must  be  enforced  by  a 
production  system;  however,  our  proof  of  concept  system  assumes  that  the  user  will  do  this. 

Since  the  number  of  tuples  within  a  relation  varies  with  time,  the  size  of  the 
tuple  sequence  is  dynamic.  Database  updates,  insertions,  deletions,  etc.  generally 
necessitate  a  modification  to  the  number  of  tuples  within  a  relation.  Therefore,  the  sequence 
of  tuples  that  comprise  the  tuples  attribute  is  a  doubly-linked  list  which  allows  the  sequence 
to  dynamically  grow  and  shrink  at  run-time. 

e.    Tupletype 

Tuple_type  is  of  the  IDB  strict  class  type  tuple.  Thus,  it  can  reference  any  of 
the  user  defined  tuples  that  comprise  relations  within  the  database.  When  a  relation  is 
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created,  the  tuplejype  attribute  must  reference  an  object  that  is  of  the  same  type  as  all 
tuples  within  the  relation.  Therefore,  an  object  should  be  created  solely  for  that  purpose  and 
then  the  tuplejype  attribute  needs  to  reference  it. 

As  discussed  in  Chapter  II,  IDB  invokes  methods  by  the  use  of  two  different 
operations:  idl_vop  and  idl_top.  Idl_top  is  used  to  invoke  a  specific  method  implementation 
within  the  class  hierarchy  while  idl_vop  invokes  the  implementation  of  a  method  that  is 
most  closely  defined  for  an  object.  For  example,  idl_print  has  a  default  implementation  that 
is  inherited  by  all  classes.  Consider  the  two  tuple  types  employee  tuple  and  project  tuple, 

both  of  which  have  specific  implementations  for  the  idl_print  method.  Both  of  these 
classes  have  tuple  as  their  superclass  and  tuple  also  has  a  specific  implementation  defined 
for  idl_print.  Thus,  there  are  now  four  implementations  for  the  one  method,  idl_print:  the 
default,  the  strict  class  tuple's,  employee  tuple's  and  project  tuple's.  Idl_top  allows  us  to 
explicitly  indicate  which  implementation  of  idl_print  is  invoked  regardless  of  which  object 
is  being  printed  while  idl_vop  invokes  the  specific  implementation  closest  in  the  hierarchy 
to  the  object  that  is  to  be  printed.  Thus,  using  idl_top,  an  employee  tuple  could  be  printed 
using  the  strict  class  tuple's  implementation.  However,  if  idl_vop  were  instead  used  to 
invoke  the  idl_print  method,  then  the  employee  tuple's  implementation  would  be  invoked. 
Tuplejype  is  used  in  an  idl_vop  operation  to  indicate  which  implementation 
of  a  method  to  invoke.  This  is  used  most  often  within  the  method  new  juple  (create  Juple 
is  its  C  implementation)  to  invoke  the  correct  implementation  of  initializejuple.  Each 
descendent  of  the  strict  class  tuple  must  have  its  own  user  defined  and  specified 
implementation  for  initializejuple. 


21.  That  is,  along  with  their  IDL  schema  definitions,  both  classes  have  redefined  the  implementation 
for  the  idl_print  method. 
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f.     Key 

The  default  key  used  in  the  R/OODBMS  is  to  check  the  value  of  every 
attribute  within  a  tuple.  Each  relation  has  at  least  one  superkey:  the  key  that  is  all  of  the 
attributes  of  the  relation.  By  definition,  each  tuple  within  a  relation  must  be  unique.  Since 

99 

a  tuple  is  comprised  of  all  its  attributes,  the  set  of  all  its  attributes  is  therefore  a  key.  When 
this  implementation  is  over-ridden  the  user  may  use  this  attribute  to  specify  some  other  key 
to  be  used  when  comparing  tuples. 

2.     Methods 

Other  than  the  relational  algebra  operations,  idl_key  method,  and  idl_print 
method  that  have  already  been  discussed,  the  IDB  node  class  relation  has  two  other 
methods  defined:  new_tuple  and  check_union_compatability.  Their  names  are  quite 
descriptive  of  their  function.  As  mentioned  earlier,  create_tuple  is  the  C  implementation  of 
the  method  new_tuple.  As  with  all  of  the  node  class  relation's  methods,  new_tuple  requires 
no  user  defined  methods.  However,  it  does  invoke  a  user  defined  and  provided  method: 
initialize_tuple  (a  method  of  the  strict  class  tuple).  The  function  of 
check_union_compatability  has  already  been  discussed  in  the  sections  pertaining  to  the 
attributes  attribute_names  and  attribute_types. 

F.      THE  TUPLE  CLASS 

User  defined  tuples  must  be  subclasses  of  the  strict  class  type  tuple.  Of  the  three 
required  classes  that  comprise  the  R/OODBMS,  tuple  is  the  only  one  that  is  not  an  IDB 
node  type.  As  such,  it  cannot  be  instantiated  into  tuples  (objects)  that  can  be  inserted  into 


22.  This  is  not  to  say  it  is  the  only  key.  There  usually  exists  other  keys  that  are  a  subset  of  attributes 
comprising  a  relation. 


82 


relations.  Instead,  the  user  must  provide  the  definition  for  tuples  that  are  descendents  of  this 
class. 

1.  Attributes 

Tuple,  as  a  strict  class  type,  has  no  attributes  defined  for  it.  There  are  no  attributes 
that  are  common  to  tuples  of  every  relation.  Thus,  it  makes  no  sense  to  define  attributes  at 
this  level  since  they  would  be  inherited  by  all  descendents. 

2.  Methods 

Each  method  defined  for  this  class  has  a  default  implementation  that  is  very 
general.  As  a  whole,  most  of  the  default  implementations  are  so  general  that  they  tend  not 
to  be  very  useful.  Users  must  provide  their  own  implementation  for  each  method  defined 
for  this  class.  Clearly,  the  implementation  of  the  method  initialize_tuple  must  be  different 
for  an  employee  tuple  than  for  a  project  tuple  since  they  likely  have  different  orders  and 
differing  domains  corresponding  to  their  attributes. 

a.  Initializetuple 

As  the  name  implies,  the  function  of  this  method  is  to  return  a  newly  created 
and  initialized  tuple.  It  has  a  tuple  as  its  only  parameter,  creates  a  new  tuple,  initializes  the 
tuple  with  valid  values,  and  returns  the  new  tuple. 

b.  Insertfields  and  Inserttuples 

The  first  approach  attempted  in  implementing  these  insert_fields  and 
insert_tuples,  which  support  the  project  operation  and  Cartesian  product  operation 
respectively,  was  unsuccessful.  Consider  the  Cartesian  product  operation:  to  form  the 
resultant  relation  each  tuple  of  the  first  operand  relation  is  concatenated  with  each  tuple  in 
the  second.  This  concatenation  process  is  continued  for  every  tuple  in  the  first  relation.  It 
therefore  seemed  logical  to  create  a  function  called  insert_tuple  that  would  take  as  its 
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parameters  two  operands,  the  tuple  to  be  inserted  and  the  resultant  tuple.  Each  user  defined 
tuple  used  within  a  relation  in  the  database  would  have  their  own  particular  implementation 
of  the  method. 

For  example,  recall  the  tuple  types  defined  by  the  schemas  in  Figure  25  and 
Figure  26.  To  insert  the  resultant  tuples  into  the  resultant  relation  for  the  operation  Cart 
Result  1  =  r3  X  ptl  (where  the  relation  Cart  Resultl  has  tuples  of  type  cartl_result_tuple, 
relation  r3  has  type  emp_tuple,  and  ptl  has  type  proj_tuple),  the  relation  r3  would  be 
iterated  through  a  tuple  at  a  time.  The  insert_tuple  method  for  r3  would  then  be  invoked  to 
insert  the  r3  tuple  values  into  the  resultant  relation  tuple.  Subsequently,  insert_tuple  would 
be  invoked  again  however,  this  time  for  ptl  which  would  insert  its  tuple's  values  into  the 
resultant  relation  tuple.  Thus,  one  complete  tuple  of  the  resultant  relation  is  complete.  This 
would  continue  with  the  first  tuple  in  r3  and  every  tuple  in  ptl.  Subsequently,  the  same 
process  would  be  done  for  the  rest  of  r3's  tuples. 

It  is  clear  that  the  resultant  tuple,  sent  as  a  parameter  to  the  insert_tuple 
method,  will  always  have  correct  attributes  to  have  values  filled  in;  however,  it  will  also 
have  other  attributes  that  will  change  from  one  invocation  to  the  next.  Additionally,  the 
tuple  to  be  entered  into  the  resultant  tuple  will  always  be  a  constant  type  belonging  to  the 
class  for  which  the  particular  insert_tuple  implementation  is  specified.  That  is,  the 
insert_tuple  implementation  for  emp_tuple  will  always  have  a  parameter  tuple  that  is  of 
type  emp_tuple,  with  attributes  person,  address,  phone,  and  widget,  to  be  inserted  into  the 
resultant  tuple.  The  resultant  tuple  parameter  sent  to  this  implementation  of  insert_tuple 
will  always  have  attributes  person,  address,  phone,  and  widget  in  addition  to  the  attributes 
essn,  proj_num,  and  hours. 

Now  the  same  operation  is  executed  again  except  with  ptl  replaced  by  a 
relation  called  R2  that  has  the  attributes  sponsor_ssn  and  dependent_name.  An  appropriate 
resultant  tuple  type,  cart2_result_tuple,  is  created  with  the  attributes  person,  address, 
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phone,  widget,  sponsor_ssn,  and  dependent_name.  This  time  when  insert_tuple  is  invoked 
for  r3  it  will  receive  two  tuples:  one  of  type  emp_tuple  and  the  other  of  type 
cart2_result_tuple.  Again  the  resultant  relation  has  the  attributes  that  this  implementation 
will  requires,  person,  address,  phone,  and  widget,  but  this  time  the  resultant  tuple  also  has 
the  attributes  sponsor_ssn  and  dependent_name.  Thus,  each  implementation  of  insert_tuple 
must  be  able  to  handle  differing  structures  for  the  resultant  relation.  This  proved  to  be 
problematic  for  both  the  insert_tuple  method  and  insert_field  method. 

The  solution  used  in  our  R/OODBMS  is  to  have  two  methods  called 
insert_tuples  and  insert_fields.  Instead  of  having  every  tuple  type  that  belongs  to  some 
relation  in  the  database,  each  resultant  tuple  type  requires  its  own  implementation.  That  is, 
in  our  example  involving  the  Cartesian  product  operation,  cartl_result_tuple  and 
cart2_result_tuple  would  both  have  their  own  implementation  of  the  method.  There  are 
now  three  parameters  to  the  method:  the  two  operand  relations  and  the  resultant  relation. 
The  entire  concatenation  process  is  completed  within  these  methods  and  the  resultant 
relation  is  returned  from  the  method  after  completion.  The  method  insert_fields  works  in  a 
similar  manner;  however,  it  requires  only  two  parameters,  the  operand  relation  and 
resultant  relation. 

c.     Comparison  methods 

The  comparison  methods  implemented  in  the  R/OODBMS  are  equal_to, 
less_than,  and  greater_than.  The  equal_to  method  is  used  by  the  check  union  compatibility 
function  and  select  operation.  Although  there  are  default  implementations  for  these  within 
the  R/OODBMS,  they  have  very  limited  applicability  since  the  possible  tuple  types  are 
limitless  and  each  generally  requires  specific  implementation  for  comparing  tuples  of  the 
same  type.  Thus,  the  default  implementations  are  a  point  of  departure,  but  users  must 
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provide  their  own  implementations  for  each  tuple  type  that  is  user  defined  if  the  R/ 
OODBMS  is  to  perform  properly. 

The  designer  of  the  comparison  operator  methods  has  many  decisions  to 
make  regarding  their  implementation.  If  the  tuple  type  is  complex  with  attributes  that  have 
a  type  that  is  a  user  defined  object,  then  deciding  at  which  level  comparisons  will  be  made 
may  be  difficult.  For  example,  in  Figure  25  the  schema  for  an  emp_tuple  class  is  shown. 
An  instance  of  this  class  has  four  attributes:  person,  address,  phone,  and  widget.  Each  of 
these  attributes  is  a  user  provided/defined  class.  Figure  32  shows  the  definition  for  these 

classes  (except  for  widget  ).  Which  level  do  the  comparison  operators  compare  at?  When 
the  person  attribute  of  an  emp_tuple  is  compared  with  another,  are  the  object  IDs  (OIDs) 
of  the  objects  that  they  reference  compared?  Or  is  every  attribute  of  the  person  object: 
fname,  mname,  lname, ...  compared?  Or  maybe  the  comparison  should  be  made  at  a  more 
detailed  level? 


person  => 

fname 

string, 

mname 

string, 

lname 

string, 

bdate 

string, 

ssn 

integer, 

spouse 

string, 

sptr 

person_nil ; 

addr  => 

street 

string, 

city 

string, 

state 

string, 

zip 

string; 

phone_number  => 

number 

string; 

Figure  32  Person,  Addr,  Phone_number  Class  Definitions 


23.  The  attribute  widget  is  an  arbitrarily  complex  attribute  that  has  yet  to  be  defined  by  the  user. 
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As  the  attributes  of  a  relation  become  more  complex,  it  is  easy  to  see  how 
many  variations  there  are  for  implementations  of  comparison  operator  methods.  By  the 
same  token,  it  is  also  easy  to  see  that  one  default  implementation  could  never  hope  to  be 
functional  for  more  than  just  the  simplest  of  attributes.  Without  user  provided 
implementations  for  the  comparison  operator  methods,  user  defined  tuple  types  in  R/ 
OODBMS  will  not  work  properly. 

3.     User  Definitions 

The  relations  that  can  be  formed  within  R/OODBMS  are  limited  only  by  what  the 
user  can  define  within  an  EDL  schema.  However,  it  is  critical  that  specific  implementations 
for  methods  inherited  from  the  IDB  strict  class  tuple  be  written  for  all  user  defined  tuple 
types.  The  implementation  of  the  relational  algebra  operations  for  the  IDB  node  class 
relation  depend  on  them. 
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V.  ALTERNATIVE  PROJECT  AND  CARTESIAN  PRODUCT 
IMPLEMENTATIONS 


A.      GENERAL 

Of  the  five  fundamental  relational  algebra  operations  (union,  difference,  select, 
Cartesian  product,  and  project),  Cartesian  product  and  project  are  considered  to  be  the  most 
difficult.  As  discussed  in  Chapter  IV,  this  is  because  the  resultant  relation  yielded  by  these 
two  operations  have  a  different  structure  from  the  operand  relation(s).  For  this  reason,  both 
ROOMS  [Ne88]  and  our  R/OODBMS  require  that  the  resultant  relation  structure  for  these 
two  operations  be  defined  by  the  user  prior  to  the  execution  of  the  operation.  This  chapter 
deals  with  an  IDB  specific  alternative  solution  to  this  approach. 

Recall  that  an  attribute  that  has  a  type  that  is  of  an  IDB  strict  class  type  can  reference 
any  object  that  is  a  descendent  of  that  strict  class  type.  Thus,  an  attribute  that  is  of  type  tuple 
can  reference  any  object  that  is  an  instantiation  of  an  IDB  node  class  type  which  is  a 
descendent  of  class  tuple.  In  both  ROOMS  and  R/OODBMS,  the  user  is  required  to  provide 
the  definition  of  the  resultant  tuple.  In  Chapter  IV,  the  only  two  resultant  relation  tuple 
types  for  Cartesian  product  and  project  operations  that  are  defined  are  cartl_result_tuple 
and  project l_result_tuple  respectively.  Hence,  any  result  of  either  of  these  two  operations 
(in  the  database  as  defined  in  the  schema  of  APPENDIX  C)  must  have  the  structure  of 
cartl_result_tuple  and  project  l_result_tuple.  That  is,  the  Cartesian  product  operation  can 
only  be  executed  on  two  relations  where  the  first  relation  has  tuples  of  type  emp_tuple  and 
the  second  relation  has  tuples  of  type  proj_tuple.  Similarly,  the  project  operation  can  only 
project  the  hours  and  essn  attributes  of  relations  that  have  type  proj_tuple. 

Say  that  you  wanted  to  perform  a  project  operation  on  a  relation  with  tuples  of  type 
proj_tuple  for  the  attributes  proj_num  and  hours.  Or,  that  you  wanted  to  take  the  Cartesian 
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product  of  a  relation  with  proj_tuple  types  and  another  with  emp_tuple  types.  In  both  cases, 
new  tuple  subclasses  for  the  resultant  relations  would  have  to  be  defined  prior  to  run-time. 
However,  there  is  an  alternative  in  IDB:  the  use  of  the  type  'any'. 

B.      IDB  TYPES 

An  attribute  in  an  EDL  schema  can  have  any  of  the  types  listed  in  Figure  33.  A  R/ 
OODBMS  relation  has  an  attribute  called  tuples  that  has  type  sequence  of  tuple  where  tuple 
is  a  IDB  strict  class  type.  Thus,  any  subclasses  of  tuple  may  be  referenced  by  the  class 
relation's  attribute  tuples.  Therefore,  a  relation's  schema  is  defined  by  the  structure  (tuple 
subclass  definitions)  of  its  tuples.  In  our  R/OODBMS,  the  user  must  provide  these  subclass 
definitions  to  define  their  relations.  In  other  words,  the  subclasses  of  class  tuple  are  all  user- 
defined  classes.  For  example,  in  Chapter  IV  two  tuple  subclasses  were  used:  emp_tuple  and 
proj_tuple.  Consider  an  Employee  relation,  it  would  have  tuples  that  are  of  type  emp_tuple. 
Our   R/OODBMS   relation's   attribute   tuples   would   then   reference   a   sequence   of 

emp_tuple. 

Another  way  to  gain  the  same  effect  as  having  the  relation's  attribute  tuples  reference 
a  different  tuple  subclass  differing  Cartesian  product  and  project  queries  is  to  define  one 
subclass  that  has  the  flexibility  to  dynamically  reference  varying  number  of  tuple  attributes 
and  differing  types  of  attributes  with  each  instantiation.  A  tuple  can  be  thought  of  as  a 
sequence  of  attribute  values,  so  if  a  linked  list  is  used  to  allow  the  flexibility  required  in  the 
sequence  size  then  we  simply  need  a  type  (this  equates  to  the  domain  of  an  attribute)  that 
can  reference  any  object  within  the  database.  That  is,  each  attribute  in  the  resultant  relation 


1.  It  is  important  to  note  that  emp_tuple  and  all  other  subclasses  of  tuple  must  be  IDB  node  class 
types.  That  is,  node  class  types  may  be  instantiated  into  objects  whereas  strict  class  types  cannot 


89 


could  have  any  domain  that  is  already  defined  in  the  database.  Any  attribute  that  is  of  type 
'any'  can  reference  any  object  within  the  database. 


reference 

string 

sequence 

array 

linked 

class 

any 

user-defined 

nil 

embedded 

primitive 

boolean 

integer 

rational 

Figure  33  IDL  Types"  [Pe91c,  p.  62] 

C.     THE  RESULTTUPLE  SUBCLASS 

In  this  alternative  implementation,  only  one  resultant  relation  tuple  type  is  needed.  It 
has  been  called  result_tuple  and  has  one  attribute,  values,  which  has  type  sequence  of  any 

(see  Figure  34  and  APPENDIX  EJ).  Thus,  this  attribute  can  reference  any  object  within  the 
database.  Since  we  cannot  anticipate  how  many  attributes  any  particular  resultant  relation 
will  have,  the  sequence  of  any  is  a  linked  list  of  any  which  allows  the  number  of  attributes 
(values)  within  a  result_tuple  to  vary  from  one  result_tuple  to  another.  Hence,  this  one  tuple 
type  can  be  used  as  the  resultant  tuple  type  for  any  operation  in  R/OODBMS. 


2.  The  difference  between  reference  and  embedded  types  is  important  to  note.  Attributes  that  are  ref- 
erence types  are  pointers  to  an  independent  object  that  contains  the  attribute  value.  In  contrast,  at- 
tributes that  are  embedded  types  have  their  value  imbedded  within  the  object  that  it  belongs. [Pe91c] 

3.  Changes  from  the  original  R/OODBMS  schema  (APPENDIX  C)  are  in  bold  in  APPENDIX  E. 
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result_cuple         =>  values    :   seq  of  any; 


Figure  34  Resultant  Relation  Schema  for  Project  and  Cartesian  Product 

Both  the  modified  project  operation  and  the  modified  Cartesian  product  operation 
create  the  resultant  relation  using  a  function  that  initializes  all  of  the  class  relation  attributes 
to  initial  values  before  the  tuples  are  inserted  into  the  relation.  In  both  cases,  the  relation 
attribute  tuples  is  initialized  to  reference  an  empty  linked  list  of  type  result_tuple.  A  pointer 
to  the  new  resultant  relation  is  passed  back  to  the  calling  function  so  that  the  tuples  can  be 
inserted  into  the  relation.  This  initialization  function  differs  for  the  two  operations  and  will 
be  discussed  in  further  detail  in  the  sections  below.  Each  of  these  initialization  functions 
(init_proj_result_rel  and  init_Cart_result_rel)  is  a  variation  of  the  init_temp_rel  used  by  the 
simple  operations  (union,  difference,  and  select). 

D.     THE  MODIFIED  OPERATIONS 

1.    Project 

There  are  a  number  of  functions  used  by  the  modified  project  operation  that  also 
required  modification.  These  functions  along  with  the  modified  project  operation, 
project_op  are  listed  in  APPENDIX  E.  Note  that  these  are  only  the  functions  from  the 
original  R/OODBMS  shown  in  APPENDIX  C.  In  order  to  have  a  working  R/OODBMS 
with  this  alternative  approach,  the  functions  in  APPENDIX  E  must  be  inserted  into  the  code 
in  APPENDIX  C.  Functions  in  the  two  appendices  that  have  the  same  name  indicate  that 
the  newer  modified  function  replace  the  identically  named  function  in  APPENDIX  C.  All 
other  functions  in  APPENDIX  E  that  have  unique  names  should  simply  be  inserted. 
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The  project  query  syntax  is  changed  to  that  shown  in  Figure  35.  The  project_op 
function  still  implements  the  project  operation.  The  difference  between  this 
implementation  and  the  original  begins  with  a  modified  function  that  parses  the  project 
query:  Project_parse_action.  There  are  fewer  tokens  to  parse  than  in  the  original 
implementation. 
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Figure  35  Modified  Project  Query 

An  additional  data  structure  is  required  by  this  implementation  since  there  is  a 
need  to  pass  an  array  of  indexes  as  a  parameter  to  the  insert_fields_b  function.  This 
structure,  index_array,  is  defined  in  the  IDL  schema  in  APPENDIX  E;  however,  since  it  is 

not  reachable  from  the  root,  it  can  never  be  written  to  the  database.  Index_array  has  one 
attribute  that  is  a  sequence  of  integers  that  are  used  to  indicate  which  attributes  will  be 
projected. 


4.  Remember  that  for  an  object  to  be  written  to  secondary  storage  in  IDB  it  must  be  reachable  from 
the  root. 
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Insert_fields_b  is  the  workhorse  of  the  function  project_op.  This  modified 
function  requires  an  additional  parameter,  index_array,  that  was  not  required  by 
insert_fields.  Otherwise,  it  still  accepts  two  other  parameters:  the  operand  relation  and 
resultant  relation.  The  user  must  provide  certain  methods  that  override  inherited  methods 
during  the  construction  of  their  relations.  For  example,  the  user  must  provide  overriding 
implementation  for  the  comparison  operators  for  each  relation.  In  the  same  vein,  the  user 
must  provide  an  overriding  implementation  for  the  insert_fields_b  method  that  they  all 
inherit.  The  reason  for  this  is  that  each  relation  has  a  different  list  of  attributes  that  may  be 
projected;  thus  one  generic  field  (attribute)  insertion  method  will  not  suffice.  In  the 
modified  R/OODBMS  schema  only  emp_tuple  had  an  overriding  implementation 
provided.  Thus,  project  operations  may  only  be  done  on  relations  with  tuples  that  are  of 
type  emp_tuple  type.  The  resultant  relation  from  a  project  operation  of  a  relation  with 
proj_tuple  types  would  yield  meaningless  results  since  no  overriding  implementation  for 
insert_fields_b  is  provided  in  the  schema. 

Each  user  provided  overriding  implementation  can  be  a  copy  of 
insert_emp_fields_b  with  a  few  modifications.  Each  attribute  must  have  its  own  case  that 
inserts  that  particular  attribute  into  the  resultant  relation  tuple  (its  index  is  in  index_array). 
In  Figure  36,  insert_emp_fields_b  has  been  modified  to  indicate  the  portions  of  the  function 
that  need  to  be  changed  for  each  relation  within  the  database.  Note  that  a  new  object  is  not 
created  for  each  attribute  that  is  inserted  into  the  resultant  relation;  instead  each  attribute  of 
the  operand  relation  that  is  to  be  projected  is  referenced  by  the  resultant  relation  tuple.  This 
issue  of  creating  an  independent  object  for  the  resultant  relation's  attributes  versus  simply 
referencing  the  attributes  of  the  operand  relation(s)  was  discussed  in  Chapter  IV  and 
therefore  it  will  not  be  discussed  again  here. 

It  should  be  noted  that  in  this  implementation  the  resultant  relation  from  a  project 
operation  cannot  itself  be  used  as  the  operand  relation  for  another  project  operation.  This 
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could  be  done  but  would  require  a  general  overriding  implementation  of  the  insert_fields_b 
method  that  would  not  conform  to  the  template  shown  in  Figure  36.  The  fundamental 
difference  between  all  user  provided  tuple  subclass  definitions  and  the  result_tuple 
definition  is  that  the  user  provided  subclasses  all  have  no  attributes  that  are  of  a  sequence 
types  while  the  only  attribute  of  the  result_tuple  is  a  sequence  type.  This  difference  will 
require  that  the  attribute  values  are  inserted  into  the  resultant  relation  by  use  of 
idl_linked_for  which  will  iterate  through  each  of  the  attributes  within  the  operand  relation's 
tuples  to  find  the  appropriate  attributes  to  insert.  This  is  in  contrast  to  using  a  case  statement 
to  insert  the  appropriate  attributes. 

The  insert_fields_b  method  returns  the  resultant  relation  to  project_op  with  all  of 
the  correct  tuples  inserted.  Finally,  the  function  project_op  inserts  the  pointer  to  the  new 
resultant  relation  into  the  sequence  of  relations  that  make  up  the  database.  Again,  the 
resultant  relation  is  not  written  to  secondary  storage  until  a  transaction  is  opened  that  allows 
writing  and  is  subsequently  committed. 
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idl_routine   relational_relation    insert_XXXX_f  ields_b(  rel,  result_rel,  index_array) 
relational_relation   rel,    result_rel; 
relational_index_array   index_array; 


{ 


idl_transaction  Cr  =  idl_get_trans  ( rel)  ,- 
relational_result_tuple  new_tuple; 

result_rel->tuples  =  idl_empty_l inked ( tr , relational_tuple) ; 

idl_linked_for  ( relational_tuple, rel->tuples, rel_tuple) 
C 

/*  iterate  through  each  tuple  and  for  each  tuple  iterate  through 

the  index_array  and  use  a  case  statement  to  reference  objects  for 
fields  to  be  entered  into  the  result  relation  */ 

new_tuple  =  idl_new( tr , relational_result_tuple) ; 
new_tuple->values  =  idl_empty_l inked  ( tr,  re lational_any)  ,- 

idl_linked_for  ( relational_index, index_array->indexes, index) 
{ 

switch  (index->i) 

case  1: 

idl_insert_back( relational_any, new_tuple->values, rel_tuple->attr  1) ; 

break; 
case  2: 

idl_insert_back(relational_any, new_tuple->values, rel_tuple->attr  2) ; 

break; 
case  3: 

idl_insert_back(  relatibnal_any,  new_tuple->values,  rel_tuple->attr  3)  ,- 

break; 


case   D: 

idl_insert_back ( relational_any, new_tuple->values, rel_tuple->attr  II) 
break; 

default : 

idl_raise( IDL_ERROR, 

"There  is  a  problem  in  the  employee  insert  field  b 

function! " ) 
break; 
} 
}  idl_end_for 

idl_insert_back( relational_tuple, result_rel->tuples, new_tuple) ; 

}  idl_end_for 


Figure  36  Template  for  Overriding  Insert_fields_b  Method 

2.     CARTESIAN  PRODUCT 

The  discussion  in  the  previous  section  regarding  modified  function's  insertion 
into  APPENDIX  C  also  applies  to  those  modified  functions  listed  in  APPENDIX  F  for 
Cartesian  product.  The  Cartesian  product  query  syntax  is  changed  to  that  as  shown  in 
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Figure  37.  The  function  cart_prod_op  implements  the  Cartesian  product  operation.  As  with 
the  project  operation,  the  new  query  syntax  dictates  that  there  are  fewer  tokens  to  parse.  As 
such,  the  function  Cartesian_parse_action  has  been  modified  to  parse  this  new  query 
syntax. 


TUB  Browser 


Cluster  View  Options  Connands  Current  Context  Heap  Help 

Car  fcesiott  Product  ■  i&MM 


rl 


->   Spea 
Davi 


=>  rel_ 
root  : 
current 
context 


Please  input  the  Cartesian  product  query  <R1  X  R2> 


Help:  connand  input  line 
Error:       — _^_ 
Response  >  ^5K3E 


Help: 

Error: 

CartesianProduct  > 


Figure  37  Modified  Cartesian  Product  Query 

The  workhorse  of  the  function  cart_prod_op  is  the  method  insert_tuples_b. 
Insert_tuples_b  still  takes  the  same  number  and  type  of  parameters  as  the  original 
insert_tuples.  In  contrast  to  the  insert_fields_b  of  the  project  operation,  the  insert_tuples_b 
method  as  defined  for  the  class  tuple  does  not  require  a  user  provided  overriding 
implementation  for  each  relation.  Instead,  the  method  insert_tuples_b  is  general  enough 
that  overriding  implementations  are  not  needed.  The  function  does  not  need  to  worry  about 
how  many  attributes  each  operand  relation  has.  It  simply  iterates  through  every  tuple  in  the 
first  operand  relation  and  concatenates  the  one  tuple  at  a  time  with  each  tuple  of  the  second 
operand  relation  (see  code  in  APPENDIX  F). 
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However,  if  the  alternative  approach  to  inserting  tuples  into  the  result  relation  is 
taken,  then  the  user  would  have  to  provide  an  overriding  implementation  of  insert_tuples_b 
for  each  relation  as  he  must  do  for  the  insert_fields_b  method  of  the  project  operation.  The 
reason  for  this  is  that  after  an  object  has  been  created  to  hold  the  tuple  to  be  entered  into  the 
resultant  relation,  the  appropriate  values  must  be  explicitly  copied  into  the  newly  created 
object.  Once  this  has  been  done,  then  the  new  object  with  the  tuples  attribute  values  can  be 
inserted  into  the  resultant  relation's  tuple. 

Since,  with  this  implementation  of  insert_tuples_b,  there  is  no  need  for  any  other 
redefinition  of  the  method,  the  resultant  relation  yielded  from  a  Cartesian  product  operation 
may  be  used  as  one  of  the  operand  relations  in  a  subsequent  Cartesian  product  query.  As 
stated  earlier,  this  is  not  possible  with  the  project  operation. 

E.      CONCLUSIONS 

This  alternative  implementation  of  project  and  Cartesian  product  appears  to  be  very 
promising.  The  project  operation  functions  in  the  manner  expected  from  a  relational 
database  perspective.  That  is,  if  you  want  to  project  attribute  3,  attribute  5,  and  attribute  1 
of  a  particular  relation,  then  the  resultant  relation  will  have  those  three  attributes  only  and 
they  will  be  in  that  particular  order.  If  you  project  attribute  5,  attribute  3,  and  attribute  1, 
then  the  resultant  relation  will  have  three  attributes  that  correspond  to  these  three  but  in  the 
order  specified  in  the  query.  Similarly,  Cartesian  product  yields  the  resultant  relation  that 
is  expected. 

There  is  one  additional  area  that  must  be  discussed,  the  displaying  of  the  resultant 
relation.  The  approach  taken  in  our  R/OODBMS  implementation  was  to  provide  a  specific 
overriding  implementation  of  the  idl_print  and  idl_key  methods  for  all  relations.  However, 
when  the  resultant  relation  is  displayed  in  this  implementation,  the  system  defined 
implementations    of    idl_print    and    idl_key    are    used    since    a    general    overriding 
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implementation  cannot  be  written  for  the  resultant  relation  as  each  resultant  relation  may 
differ  in  structure.  This  makes  it  somewhat  difficult  to  view  the  tuples  of  the  resultant 
relation.  However,  this  can  easily  be  overcome  as  demonstrated  in  Nelson's 
implementation  of  ROOMS  [Ne88]  by  having  a  display  (overriding  implementation  of 
idl_print  and  idl_key  in  this  implementation)  implementation  for  every  object  in  the 
database.  That  is,  if  an  attribute  of  a  relation  is  itself  an  object,  then  that  object  would  have 
a  specific  implementation  of  the  idl_print  and  idl_key  methods. 
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VI.  CONCLUSION 

The  purpose  of  this  research  was  to  implement  a  combined  relational/object-oriented 
database  management  system,  R/OODBMS,  that  will  overcome  the  deficiencies/ 
constraints  of  separate  relational  and  object-oriented  systems.  This  thesis  expands  previous 
work  in  this  area  that  showed  basic  proof  of  concept  by  implementing  relational  operations 
in  an  object-oriented  programming  language  which  did  not  provide  for  persistent  objects 
[Ne88][NMO90],  and  by  implementing  relational  operations  in  an  object-oriented 
programming  language  which  does  provide  for  persistent  objects  [Fi92].  A  R/OODBMS  as 
implemented  in  IDB,  a  commercially-available  object-oriented  database  management 
system,  demonstrates  the  extension  of  previous  work  to  a  commercially-available  object- 
oriented  database  management  system. 

A.     SUMMARY 

A  detailed  literature  review  investigating  object-oriented  programming  concepts, 
relational  database  management  systems,  object-oriented  database  management  systems 
(including  a  detailed  overview  of  IDB),  and  a  brief  discussion  of  previous  work  in  the  area 
was  accomplished.  Limitations  of  conventional  relational  database  management  systems 
and  object-oriented  database  management  systems  were  explored  while  identifying 
desirable  properties  of  a  combined  approach. 

The  R/OODBMS,  as  described  in  Chapter  IV,  is  specific  to  an  implementation  of 
ROOMS  [Ne88][NMO90]  in  IDB.  However,  as  with  previous  work  in  this  area,  this 
research  demonstrates  the  validity  of  the  ROOMS  concept  and  further  completes  and 
strengthens  the  proof  of  concept  started  by  Nelson  [Ne88]. 
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B.  CONCLUSIONS 

A  combination  of  relational  and  object-oriented  database  management  systems,  a  R/ 
OODBMS  is  a  logical  and  viable  solution  in  overcoming  each  individual  system's 
limitations  providing  the  best  of  both  worlds  within  a  single  system.  In  a  R/OODBMS,  the 
relational  paradigm  gains  the  ability  to  model  and  manage  arbitrarily  complex  data  that 
traditional  RDBMS  are  unable  to  handle.  Additionally,  the  object-oriented  paradigm  gains 
the  acceptance,  standardization,  and  firm  theoretical  foundation  that  traditional  RDBMSs 
enjoy.  Thus,  a  single  system  can  satisfy  the  requirements  of  users  of  both  traditional 
systems  and  overcome  many  of  their  individual  limitations. 

C.  FUTURE  RESEARCH  SUGGESTIONS 

Future  research  in  this  area  should  generally  be  focused  on  the  development  of  a 
production  system.  The  methods  used  to  implement  the  five  fundamental  relational  algebra 
operations  could  be  rewritten  with  efficiency  and  optimization  in  mind.  During  the 
implementation  of  the  R/OODBMS  in  IDB  as  presented  in  this  thesis,  neither  efficiency  nor 
optimization  were  of  great  importance.  Instead,  the  focus  was  on  constructing  an 
implementation  that  was  functional. 

In  constructing  queries,  the  user  of  our  R/OODBMS  does  not  have  the  option  of 
naming  the  resultant  relation  for  those  operations  (union,  difference,  and  select)  that  create 
the  resultant  relation.  The  R/OODBMS  creates  a  default  name  and  assigns  it  to  the  resultant 
relation.  A  production  system  should  allow  the  user  the  option  to  provide  a  name  for  the 
resultant  relation  if  desired  or  to  accept  the  default  name  provided  by  the  system.  For 
example,  a  query  of  the  form  'Rl  union  R2'  would  indicate  that  the  user  is  willing  to  accept 
the  default  name  that  the  system  provides.  However,  a  query  of  the  form  'R3  =  Rl  union 
R2'  would  indicate  that  the  user  would  like  the  relations  Rl  and  R2  to  be  unioned  together 
and  the  result  relation  to  be  name  R3. 
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There  are  several  issues  that  will  remain  as  design  decisions  for  a  production  system. 
One  issue  involves  how  objects  of  the  same  class  are  compared  with  one  another.  Are  two 
objects  equal  if  they  both  reference  the  same  ODD?  Or,  should  every  attribute  of  the  objects 
be  compared  to  determine  if  each  corresponding  attribute  has  the  same  value  for  each 
object?  A  similar  problem  arises  with  the  inequality  comparison  operators.  When  is  one 
object  greater  than  another?  Even  for  complex  objects  that  have  attributes  which  are  simple, 
this  issue  becomes  difficult. 

For  example,  consider  an  employee  of  a  company  that  has  a  first  name,  middle  name, 
last  name,  phone  number,  and  street  address.  When  the  relation  is  defined  within  the  R/ 
OODBMS,  the  relation  could  be  called  Employee  and  have  tuples  of  type  employee_tuple. 
An  employee_tuple  might  have  three  attributes  defined:  full_name,  phone_number,  and 
address  where  full_name  and  address  are  objects  and  phone_number  is  an  integer  (a  local 
phone  number  without  area  code).  The  object  full_name  has  attributes  first_name, 
middle_name,  and  last_name  where  each  attribute  is  a  string.  Address  has  attributes  street, 
city,  state,  and  zip_code  where  street,  city  and  state  are  strings  and  zip_code  is  an  integer. 
Now,  consider  the  equal  comparison  operator.  If  we  are  trying  to  compare  two  employee 
tuples  from  two  different  relations,  it  is  easy  to  determine  if  the  phone_number  in  one  tuple 
is  equal  to  that  of  another.  The  value  is  simple  an  integer  that  may  be  compared  directly. 
However,  what  if  it  is  desirable  to  compare  the  full_name  attribute?  Realizing  that  it  is  itself 
an  object,  do  we  move  to  that  object  and  consider  each  of  its  attributes  (first_name, 
middle_name  and  last_name)  as  a  whole?  Do  we  compare  OIDs?  Or,  do  we  allow  a  single 
attribute  of  full_name  to  be  compared,  such  as  only  last_name?  Or,  do  we  allow  any 
combination  of  the  attributes  to  be  compared  for  equality?  This  example  can  be  generalized 
for  any  of  the  comparison  operators  whether  they  are  equality  or  inequality  comparison 
operators. 
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The  issue  of  comparison  operator  implementation  is  also  of  concern  in  the  set 
operations  union  and  difference  during  the  determination  of  union  compatibility  and  the 
determination  of  whether  a  tuple  is  a  duplicate  of  another  tuple  within  a  relation.  This  issue 
is  also  present  in  the  select  operation  where  attributes  of  different  tuples  are  compared 
during  as  part  of  the  selection  criteria. 

The  assumption  was  made  during  this  implementation  of  a  R/OODBMS  that  the  user 
made  no  errors.  Therefore,  limited  error  checking  was  built  into  the  system.  A  production 
system  would  require  extensive  error  checking  for  all  of  the  relational  algebra  operations. 

Another  issue  is  found  in  the  insertion  of  tuples  into  resultant  relations.  Our  R/ 
OODBMS  uses  two  methods  of  insertion:  by  reference  or  by  creation.  That  is,  the  tuples  of 
the  resultant  relation  may  have  new  tuples  created  and  then  the  values  that  the  tuple  is  to 
have  are  copied  into  the  attributes  of  the  tuple.  Alternatively,  the  tuples  of  a  resultant 
relation  can  simply  be  a  reference  to  the  tuple  that  contains  the  values  to  be  inserted. 

In  this  second  approach,  two  (or  more)  different  relations  can  refer  to  the  same  tuple. 
Thus,  a  change  to  the  tuple  in  either  relation  is  reflected  in  the  other  relation.  This  approach 
is  problematic  since  if  there  is  a  duplicate  tuple  in  two  relations  that  are  being  unioned 
together,  the  resultant  relation  will  only  reference  one  of  the  two.  Now,  a  change  to  the 
tuple  in  the  resultant  relation  will  be  reflected  in  only  one  of  the  two  operand  relations.  This 
is  not  very  consistent  and  requires  that  the  user  be  aware  of  how  the  system  determines 
which  tuple  is  going  to  be  referenced  in  the  resultant  relation.  If  the  first  approach  is  used, 
the  problem  is  alleviated  since  every  tuple  in  the  resultant  relation  is  independent  of  every 
tuple  in  any  of  the  operand  relations. 

Finally,  the  project  operation  in  a  production  system  should  allow  the  user  to  rename 
the  attributes  being  projected  into  the  resultant  relation.  However,  the  issue  of  attributes 
that  are  complex  objects  comes  to  light  again.  In  our  employee  example,  if  a  project 
operation  were  used  to  project  all  the  names  of  employees  and  to  change  the  name  of  the 
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attribute  in  the  resultant  relation,  is  the  user  only  allowed  to  change  the  attribute  full_name 
to  some  other  name?  Or,  is  the  user  allowed  to  change  each  of  the  attribute  names  (such  as 
first_name,  middle_name,  and  last_name)?  Or,  is  the  user  allowed  to  change  any  one  or 
more  of  these  attribute  names? 

Additionally,  our  R/OODBMS  requires  the  user  to  form  a  select  query  using  the 
syntax  'Rl  select  <attribute  name>  <comparison  operator>  <comparison  object>'  where 
the  comparison  object  has  the  same  superclass  as  Rl  and  has  only  a  single  tuple.  A 
production  system  should  also  allow  the  user  to  construct  a  select  query  of  the  syntax  'Rl 
select  <attribute  name>  <comparison  operator>  <value>'  where  value  is  the  display  form 
<attribute  name>.  For  example,  in  our  employee  example,  the  user  should  be  allowed  to 
enter  the  query  'Rl  select  phone_number  =  3758619'. 
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APPENDIX  A:  EXAMPLE  IDL  SCHEMA 


structure  vhc  root  diet  is 

diet  =>  local  :  fleet, 

remote  :  cross  of  fleet; 

fleet  =>       vehicles  :  seq  of  vehicle; 
vehicle  ::=  train  I  plane; 

vehicle  =>   location  :  city, 

destination  :  city_nil; 
vehicle  ->  move (*, city, city) ; 

city  =>  name  :  string; 

city_nil  ::=      city  I  nil; 

train  ::=  ptrain  I  f train; 

train  =>  cars  :  seq  of  car; 

car  =>  number  :  integer; 

ptrain  =>;  ftrain  =>; 

plane  ::=  pplane  I  fplane; 

plane  =>  airborne  :  boolean; 

pplane  =>;  fplane  =>; 

passenger  ::  =  ptrain  I  pplane; 

passenger  =>  max  :  integer, 

passengers        :  seq  of  person; 

freight  ::=  ftrain  I  fplane; 

freight  =>  cargo_weight      :  rational; 

person  =>  name  :  string; 

for  fleet .vehicles  use  linked; 
for  train. cars  use  linked; 
for  passenger .max  use  unsigned; 
for  passenger .max  use  bytes(2); 

for  vehicle. idl_print  use  bind (vehicle_print ) ; 
for  train. idl_print  use  bind(train_print ) ; 
for  vehicle. move  use  bind(vehicle_move) ; 

for  vehicle. location  use  search; 

for  vehicle. location  use  search_embed; 

for  ptrain  use  description ( "passenger  train"); 

for  ftrain  use  description ( "freight  train"); 

for  pplane  use  description ( "plane  (passenger)"); 

for  fplane  use  description ( "air  freight"); 

for  passenger .max  use 

description ( "maximum  number  of  passengers"); 
end 
process  vhep  is  vhc  ::=  vhea  :  access;  end 
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APPENDIX  B:  DATABASE  DIRECTORY  SOURCE  CODE 


***************************************************** 

--  dbdir.idl 

Schema  for  database  directory 

--  Description: 

A  directory  cluster  is  used  to  group  together  other  clusters  into 
a  directory.  In  this  directory,  the  clusters  are  databases. 

**************************************************************************** 

structure  dbdir  root  seq  of  database  is 
for  root  use  linked; 


database  =>  dbname 
file 
desc 
examine 


string,  --  database  name 

string,  --  database  file  name 

string,  --  description  of  database  cluster 

boolean;  --  default  initial  transaction 


for  database .dbname  use  description ( "database  structure  name"); 

for  database . file  use  description ( "database  cluster  file  name"); 

for  database .desc  use  description ( "description  of  the  database  cluster"); 

for  database. examine  use  description ( "enter  in'examine  mode?"); 

for  database. desc  use  search; 

database  ->  enter (*, boolean)  =>  boolean; 

for  database. enter  use  browser_cond_visible; 

for  database. enter  use  description ( "enter  this  cluster"); 

for  database. idl_key  use  bind (dbdir_key ) ; 
for  database . idl_print  use  bind  (dbdir_print )  ,- 
for  database. idl_create  use  bind (dbdir_icreate) ; 
for  database. enter  use  bind(dbdir_enter) ; 

end 

process  dbdirp  is 

dbdir  ::=  dbdira :access; 

end 
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/***************************************************************************** 

* 

*  dbdir.c 
* 

* 

*  Description: 
* 

*  This  module  provides  the  operations  for  IDB  database  directories. 

*  This  module  is  considered  to  be  part  of  the  IDB  browser.   It  invokes 

*  internal  browser  routines  to  enter  and  exit  database  clusters. 
* 
*****************************************************************************/ 

# include  "stdio.h" 
#include  "idlrt.h" 
#include  "dbdira.h" 
# include  "dpy.h" 
#include  "brwa.h" 
#include  "brw.h" 
#include  "brwi.h" 

static  char  buff  [100]; 

/***************************************************************************** 
* 

*  OPERATIONS 

* 

*  _brw_dbdir_key ( *)  --  print  short  form  db  description 

*  _brw_dbdir_print ( *,mode)  --  print  full  display 

*  _brw_dbdir_icreate ( tr)  =>  *  --  create  database  object 

*  _brw_dbdir_enter (*, boolean)  =>  boolean   --  enter  cluster 


***************************************************************************** 


/ 


idl_routine  void  _brw_dbdir_key (db) 
dbdir_database  db; 

{ 

dpy_cstring (db->desc) ; 
} 
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idl_routine  void  _brw_dbdir_print (db,mode) 
dbdir_database  db; 
dpy_dmode  mode; 
{ 

if  (mode. expand  >  0) 
{ 

idl_top (idl_any , idl_print , (db,mode) ) ; 
return; 
} 
dpy_open ("", false) ; 

dpy_attr ( dbdi r_dat aba se,db,desc, mode) ; 
if  {idl_get_display (dbdir_database, dbname) ) 
{ 

dpy_eol ( ) ; 

dpy_cstring  (  "  type  :  "  )  ; 

dpy_attr (dbdir_database,db, dbname, mode) ; 
} 
if  (idl_get_di splay ( dbdi r_dat abase,  file) ) 
{ 

dpy_eol ( ) ; 

dpy_cstring ( " file : " ) ; 

dpy_attr (dbdir_database,db, file, mode) ; 
} 
if  (idl_get_di splay ( dbdi r_dat abase, examine) ) 
{ 

dpy_eo 1 ( ) ; 

dpy_cstring ( "examine : " ) ; 
dpy_attr (dbdir_database, db, examine, mode) 
} 
dpy_close ( ) ; 
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static  dbdir_database  new_db; 

idl_routine  void  _brw_dbdir_dact ion (check) 

integer  check; 
{ 

_idl_not_used (dummy ) ; 
if  (check  ==  1) 
{ 

integer  fd; 

string  full_name  =  _brw_map_db(new_db->dbname) ; 

if  (idl_string_size (new_db->dbname)  ==  0) 

{ 

dpy_error ( "no  database  name  specified"); 
return; 
} 
(void)  sprint f (buf f , "%s .bst" , full_name) ; 
if  (fd  >  0) 
{ 

(void)  close ( fd) ; 
} 
else 
{ 

(void)  sprintf (buf f, "unable  to  find  symbol  table  file  %s.bst", 

full_name) ; 
dpy_error (buf f ) ; 
return; 
} 
if  (idl_string_size (new_db->f ile)  ==  0) 
{ 

dpy_error ( "no  structure  name  specified"); 
return; 
} 
if  ( idl_string_size (new_db->desc)  ==  0) 
{ 

new_db->desc  =  new_db->f ile; 
dpy_error ("defaulting  description") ; 
return; 
) 
} 
dpy_quit ( ) ; 
} 

idl_routine  void  _brw_dbdir_sscreen (a, x,y ) 

integer  a,x,y; 
{ 

dpy_dmode  mode; 

_idl_not_used (a) ; 

mode  =  dpy_dmode_def aul t ; 

dpy_open ( "Define  New  Database" , true) ; 

dpy_open ( "New  Database" , true) ; 

brw_cmd( "Check", "check  and  exit  if  correct" ,_brw_dbdir_daction, 1L, BRW_SCREEN) 

dpy_spacex ( 5L) ; 

brw_cmd ("Nocheck" , "exit  without  checking" ,_brw_dbdi r_dact ion, 0L, BRW_SCREEN) ; 

dpy_eol ( ) ; 

dpy_spacey (2L) ; 

dpy_eol ( ) ; 

mode. expand  =  1  ; 

idl_vop (new_db,dbdir_database, idl_print ,  ( new_db , mode ) ) ; 

dpy_close ( ) ; 

brw_input_area (y-3 , false) ; 

dpy_close ( ) ; 
dpy_boxed (x,y ) ; 
) 
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idl_routine  dbdir_database  _brw_dbdir_i create ( tr) 

idl_transaction  tr; 
{ 

string  empty  =  idl_copy_string ( tr , " " ) ; 

new_db  =  idl_new ( tr ,dbdir_database) ; 

new_db- >dbname  =  empty; 

new_db->file  =  empty; 

new_db->desc  =  empty; 

new_db->examine  =  true; 

dpy_active (_brw_dbdir_s screen, OL) ; 

return  new_db; 


idl_routine  boolean  _brw_dbdir_enter (db, test] 
dbdir_dat abase  db; 
boolean  test; 


{ 


if  (!  test) 
{ 

integer  tkind  =  BRW_READ; 
idl_if  (brw_tr,_brw_dict->curr_tr, btr) 
{ 

(void)  sprint f (buff , "%s/%s" , btr->name, db->desc; 
} 
idl_else 
{ 

(void) .  sprint f (buff , " **unknown**/%s" , db->desc)  ; 
}  idl_end_if 

/*  open  new  transaction  */ 
if  (db->examine)  tkind  =  BRW_EXAMINE; 
(void)  _brw_topen ( idl_copy_string (brw_static, buff) , 
db->dbname, db->f ile, 
OL, 

BRW_NORMAL, tkind, true) ; 
} 
return  true; 


idl_def ine_ops  dbdir_opbind ( ) 
{ 

idl_bind_root (dbdir) ; 

idl_bind( "dbdir_key" , _brw_dbdir_key ) ; 

idl_bind( "dbdir_print" ,_brw_dbdir_print ) ; 

idl_bind( "dbdir_icreate" ,_brw_dbdir_i create) ; 

idl_bind( "dbdir_enter" ,_brw_dbdir_enter ) ; 
} 
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1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 

IDL  SCHEMA 

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 


A  Relational/Object-Oriented  Database  Management  System 
relational . idl 


-Title 
-File  name 
-Associated 

files 
-Author 
-Date 

-Advisor 
-Second 

Reader 
-System 
-Compiler 
-Translator 
-Description 


relational. c  relationala . h  relational . bst  relational . so 
Ronald  L.  Spear 
24  September  1992 
Master's  Thesis 
Maj  Mike  Nelson 

Prof.  Thomas  Wu 

Sun  4/60  Workstation,  Unix  Operating  System 

AT&T  C 

IDL  vl.l,  Persistent  Data  Systems 

This  file  contains  the  IDL  schema  for  the  implementation  of 

A  Relational/Object-Oriented  Database  Management  System. 


structure  relational  root  database  is 

****************************************************************************** 

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 

Database  Schema 
1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 II 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 


database  => 


name 
relations 


string, 

seq  of  relation; 


database  ->    new_relation( *)  ; 


1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1  / 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 

Relation  Schema 
1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 


relation  =>    relation_name 

attribute_names 

attribute_types 

tuples 

tuple_type 

key 


relation  -> 


name  => 


string, 

seq  of  name, 

seq  of  name, 

seq  of  tuple, 

tuple, 

string; 


relation  ->    new_tuple ( * ) , 

check_union_compatability (relation, relation)  =>  boolean; 


union ( * ) , 
projection! * ) / 
difference ( * ) , 
Cartesian_product ( * ) , 
selection (*) ; 


name 


string; 
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1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 

Tuple  Schema 

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 

tuple  ->       equal_to ( tuple, tuple, integer)  =>  boolean, 

less_than ( tuple, tuple, integer)  =>  boolean, 

greater_than( tuple, tuple, integer)         =>  boolean, 

initialize_tuple ( tuple)  =>  tuple, 

insert_f ields (relation, relation)  =>  relation, 

insert_tuples (relation, relation, relation)  =>  relation; 

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 II 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 

Tuple  Subclasses 
1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 

tuple  : : =      emp_tuple  I 
proj_tuple  I 
cartl_result_tuple  I 
projectl_result_tuple  I 
nil; 

****************************************************************************** 

for  database . new_relation  use  browse r_vi si ble; 

for  relation .new_tuple  use  browser_visible; 

for  relation .union  use  browser_visible; 

for  relation. Cartesian_product  use  browser_visible; 

for  relation .difference  use  browser_visible; 

for  relation .pro jection  use  browse r_vi si ble; 

for  relation .selection  use  browser_visible; 

for  database . relations  use  linked; 
for  relation. tuples  use  linked; 

__********************  Database,  Relation,  and  Tuple  Methods  ******************** 

for  database . idl_key  use  bind(database_key ) ; 
for  database. idl_print  use  bind(database_print ) ; 
for  database . new_relation  use  bind (create_relation) ; 

for  relation. idl_key  use  bind(relation_key ) ; 

for  relation. idl_print  use  bind( relation_print) ; 

for  relation .new_tuple  use  bind(create_tuple) ; 

for  relation. check_union_compatability  use  bind(ck_union_compatability ) ; 

for  relation .union  use  bind(union_op) ; 

for  relation .Cartesian_product  use  bind(cart_prod_op) ; 

for  relation .difference  use  bind (set_dif f_op) ; 

for  relation .projection  use  bind (project_op) ; 

for  relation. selection  use  bind(select_op) ; 

for  name.idl_key  use  bind(name_key ) ; 
for  name . idl_print  use  bind(name_print ) ; 

for  tuple. equal_to  use  bind(equal_to) ; 

for  tuple. less_than  use  bind (less_than) ; 

for  tuple. greater_than  use  bind(greater_than) ; 

for  tuple. initialize_tuple  use  bind( initialize_tuple) ; 
for  tuple. insert_f ields  use  bind (insert_f ields ) ; 
for  tuple. insert_tuples  use  bind ( insert_tuples ) ; 


111 


************************************* gjjin    tuple******************************** 

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 

Employee   Tuple   Schema 
1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 


emp_tuple   => 


person   => 


person 

person, 

address 

addr, 

phone 

phone_number 

widget 

idl_univ; 

f  name 

string, 

mname 

string, 

lname 

string, 

bdate 

string, 

ssn 

integer, 

spouse 

string, 

sptr 

person_nil; 

person_nil    ::=   person    I    nil; 


addr   => 


phone_number   =>        number 


.*********************************** 


street 

string, 

city 

string, 

state 

string, 

zip 

string; 

string; 

emp_tupl e  me thods ************************** 


for  emp_tuple. idl_key  use  bind (emp_tuple_key ) ; 

for  emp_tuple. idl_print  use  bind (emp_tuple_print ) ; 

for  emp_tuple . equal_to  use  bind (emp_equal_to) ; 

for  emp_tuple . less_than  use  bind (emp_less_than) ; 

for  emp_tuple . greater_than  use  bind (emp_greater_than) ; 

for  emp_tuple. initialize_tuple  use  bind(initialize_emp_tuple) ; 

for  person . idl_key  use  bind ( per son_key) ; 
for  person . idl_print  use  bind (person_print ) ; 

for  addr.idl_key  use  bind(addr_key )  ,- 
for  addr . idl_print  use  bind(addr_print ) ; 

for  phone_number . idl_print  use  bind(phone_number_print ) ; 
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************************************p£-o-j  t;uple******************************** 

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 

Project  Tuple  Schema 
1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 


proj_tuple  => 


essn 

proj_num 

hours 


integer, 
integer, 

rational 


.*********************************r->£-Q-j  tuple  mehods  *  **************************  ■ 

for  proj_tuple . idl_key  use  bind (proj_tuple_key ) ; 

for  proj_tuple.  idl_print  use  bind(proj_tuple_print ) ; 

for  proj_tuple . equal_to  use  bind (pro j_equal_to) ; 

for  proj_tuple . less_than  use  bind(proj_less_than) ; 

for  proj_tuple .greater_than  use  bind (proj_greater_than) ; 

for  proj_tuple  .  initialize_tuple  use  bind(initialize__proj_tuple)  ; 


.********************************* 


cartl_result_tuple'i 


**************** 


1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 

Cartesianl  Result  Tuple  Schema 
1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 II 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 


cartl_result_tuple  => 


person  ■ 

address 

phone 

widget 

essn 

proj_num 

hours 


person, 

addr, 

phone_number , 

idl_univ, 

integer^ 

integer, 

rational ; 


,*********■ 


******* 


* ** **cartl_result_tuple  methods 


*********************** 


for  cart l_result_tuple . idl_key  use  bind(cartl_result_tuple_key ) ; 
for  cartl_result_tuple . idl_print  use  bind(cartl_result_tuple_print ) ; 
for  cartl_result_tuple . initialize_tuple  use 

bind ( initialize_cart l_resul_tuple) ; 
for  cartl_result_tuple . insert_tuples  use  bind( insert_cartl_result_tuples) ; 


************! 


*************************************************************** 


I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I   I    I   I    I   I    I   I    I   I    I   I    I   I    I    I    I    I    I    I    I    I    I    I    I   I    I    I    I    I    I   I    I   I    I    I    I  I    I    I    I    I    I    I    I    I    I   I    I    I    I    I    I    I    I    I    I   I    I   I    I   I    I    I    I 

Projectl  Result  Tuple  Schema 
1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 


projectl_result_tuple 


************************* 


=>  hours 
essn 


rational 
integer; 


rprojectl_result_tuple  methods********** 


************ 


for  projectl_result_tuple. idl_key  use  bind (pro j ect l_resul t_tuple_key ) ; 
for  projectl_result_tuple. idl_print  use  bind (pro jectl_result_tuple_print ) ; 
for  projectl_result_tuple. initialize_tuple  use 

bind (ini tialize_projectl_resul_tuple) ; 
for  projectl_result_tuple . insert_f ields  use  bind (insert_projectl_result_f Ids) ; 


._***********■ 


■**************: 


********************************************* 


end 
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Ic**********************************************************************^***** 

process  relationalp  is 

relational  ::=  relationala raccess; 
end 
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■it*********************************' 


it*****************-*******: 


:****** 


R/OODBMS  FUNCTIONS 


*********************************: 


******************************* 


/■■ 


A  Relational/Object-Oriented  Database  Management  System 

relational .c 

Ronald  L.  Spear 

24  September  1992 

Master's  Thesis 

Maj  Mike  Nelson 


*  Title 

*  File  name 

*  Author 

*  Date 
* 

*  Advisor 

*  Second 

*  Reader 

*  System 

*  Compiler 

*  Translator 

*  Description 


Prof .  Thomas  Wu 

Sun  4/60  Workstation,  Unix  Operating  System 

AT&T  C 

IDL  vl.l,  Persistent  Data  Systems 

The  functions  in  this  file  run  with  the  IDB  Object  Database 

system  version  1.1.  The  file  containing  the  schema  for  these 

*  methods  is  relai tonal . idl .  The  relational . idl  file  was 

*  translated  using  the  IDL  translator  and  produced  the 

*  relationala . h  header  file  which  is  included  for  use  with 

*  this  file. 

*  ====  =  ===  =  =  =  =  =  =  =  ===  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  = ====  =  =  =  ===================  =  ===  =  =  = 

*/ 

tinclude  <string.h> 
#include  "idlrt.h" 
#include  "relationala . h" 
# include  "dpy.h" 
#include  "brw.h" 

*    Macros  defined  for  Class  person 

* 


***************- 


#define  exists(v)  idl_string_size (v)  !=  0 

ttdefine  rexists (node, attr)  (idl_get_display (relational_person, attr)  &&  \ 
(node->attr  !=  0  &&  \ 
exists (node->attr) ) ) 

#define  dexists (node, attr )  (mode. expand  >  0  II  rexists (node, attr) ) 

#define  prexists (node, attr)  ( idl_get_display ( relational_person, attr )  &&  \ 
(node->attr  !=  0) ) 

#define  pdexists (node, attr)  (mode. expand  >  0  ||\ 
prexists (node, attr) ) 
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* 

*    Forward  References  for  all  functions  other  than  _print  and  _key 

* 

it****************************************************************************/ 

idl_routine  void  init_rel_screen( ) ; 

idl_routine  void  create_relation ( ) ; 

idl_routine  void  init_action ( ) ; 

idl_routine  void  init_tuple_screen( ) ; 

idl_routine  void  create_tuple ( ) ; 

idl_routine  boolean  ck_union_compatability ( ) ; 

idl_routine  void  exit_action ( ) ; 

idl_routine  void  char_screen ( ) ; 

idl_routine  void  integer_screen ( ) ; 

static  void  union_parse_action ( ) ; 

idl_routine  relational_relation  ini t_temp_rel ( ) ; 

void  report_union_error ( ) ; 

static  void  dif f erence_parse_action ( ) ; 

void  report_dif ference_error ( ) ; 

static  void  Cartesian_parse_action ( )  ; 

void  report_Cart_product_error ( ) ; 

static  void  Pro ject_parse_action ( ) ; 

void  report_project_error ( ) ; 

static  void  Select_parse_action ( ) ; 

void  report_select_error ( ) ; 

idl_routine  void  union_op(); 

idl_routine  void  cart_prod_op ( ) ; 

idl_routine  void  set_dif f_op ( ) ; 

idl_routine  void  project_op ( ) ; 

idl_routine  void  select_op ( ) ; 

idl_routine  boolean  equal_to(); 

idl_routine  boolean  less_than ( ) ; 

idl_routine  boolean  greater_than ( ) ; 

idl_routine  boolean  emp_equal_to ( ) ; 

idl_routine  boolean  emp_less_than ( ) ; 

idl_routine  boolean  ernp_greater_than  ( )  ; 

idl_routine  boolean  proj_equal_to ( ) ; 

idl_routine  boolean  proj_less_than ( ) ; 

idl_routine  boolean  pro j_greater_than ( ) ; 

idl_routine  relational_relation  insert_f ields ( ) ; 

idl_routine  relational_relation  insert_tuples ( ) ; 

idl_routine  relational_tuple  initialize_emp_tuple ( ) ; 

idl_routine  relational_tuple  initialize_tuple ( ) ; 

idl_routine  relat ional_tuple  initialize_pro j_tuple ( ) ; 

idl_routine  relational_tuple  initialize_cartl_resul_tuple ( ) ; 

idl_routine  relational_relation  insert_cartl_result_tuples ( ) ; 

idl_routine  relational_tuple  initialize_projectl_resul_tuple ( ) ; 

idl_routine  relational_relation  insert_projectl_result_f Ids ( ) ; 
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/***************************************************************************** 

*  Class  database  methods 

* 

*  database_key 

*  database_print 

*  create_relation 
* 
*****************************************************************************/ 

******************************************************************************** 

Class  Database  Methods 

******************************************************************************** 

/*  displays  a  short  description  of  a  database  object  */ 

idl_routine  void  database_key (database) 
relational_database  database; 

{ 

idl_univ  u; 

if  (idl_string_size (database->name)  ==  0) 
{ 

dpy_cstring ( " **  Unnamed  Database  **"); 
} 
else 
{ 

u  =  idl_to (idl_univ,database->name) ; 
idl_vop (u, idl_univ, idl_key , (u) ) ; 
} 
} 
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/*  diplays  a  database  object  */ 

idl_routine  void  database_print (database, mode) 
relational_database  database; 
dpy_dmode  mode; 

{ 

idl_transaction  tr  =  idl_get_trans (database)  ; 
boolean  can_write  =  idl_trans_write_count (tr)  >  0; 
dpy_dmode  model; 

model  =  mode; 
model . embed  =  1  ; 

if  (can_write) 
{ 

model. expand  =  1; 
mode. expand  =  1; 
} 

if  (model .expand  >  1) 
{ 

idl_top (idl_any , idl_print ,  (database, mode) ) ; 
} 

dpy_attr ( relational_database, database, name, mode) ; 
dpy_eol ( ) ; 
dpy_spacey ( 2L ) ; 
dpy_eol ( )  ; 

dpy_attr (relational_dat abase, database, relations, model ) ; 
dpy_eol ( ) ; 
} 

/*  =  =  =  =  =  =  =  =  ===  =  =  =  ===  =  =  =  =  :;  =  =  ===  =  =  =  =  =  =====  =  ===  =  =========  =  === 
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static  relational_relation  init_relation;  /*  global  ptr  to  new  rel  to 

be  initialized  */ 

/*  this  function  provides  the  user  a  pop-up  screen  in  the  browser  from  which 
he  may  edit/initialize  the  values  of  a  new  relation.  It  is  called  by 
create_relation.  */ 

idl_routine  void  init_rel_screen (a, x,y ) 

integer  a,x,y; 
{ 

dpy_dmode  mode; 

mode  =  dpy_dmode_def ault ; 

dpy_open ("Initialize  New  Relation" , true) ; 

dpy_open ( "New  Relation" , true)  ; 

brw_cmd( "EXIT" , "exit  initialization  screen" , init_action, OL, BRW_SCREEN) ; 

dpy_eol ( ) ; 

dpy_spacey (2L) ; 

dpy_eol ( ) ; 

mode. expand  =  1;  /*  forces  the  display  of  all  attributes  */ 

/*  execute  the  print  method  for  the  database  class/type  */ 

idl_vop ( init_relation, relational_database, idl_print , ( ini t_relat ion, mode) ) ; 

dpy_close ( ) ; 

brw_input_area (y-3 , false) ; 

dpy_close ( ) ; 
dpy_boxed(x,y)  ; 
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/*  Create  Relation  creates  a  new  relation  within  a  database.*/ 

idl_routine  void  create_relation (database) 

relational_database  database; 
{ 

relational_relation  new_relation; 

idl_transaction  tr  =  idl_get_trans (database ) ; 

string  empty  =  idl_copy_string ( tr , " " ) ; 

boolean  is_writable  =  ( idl_trans_write_count ( tr )  >  0) ; 

new_relation  =  idl_new( tr , relational_relation) ;  /*  must  still  assign 

legal  values,which  is 
done  below.  */ 

new_relation->relation_name  =  empty; 

/*  this  is  only  done  to  make  attribute  names  valid.  An  array  with  a  different 
size  can  be  created  while  in  the  browser  and  new_relation->attribute_names 
can  be  switched  to  reference  it  if  a  larger  array  is  needed.  */ 

new_relation->attribute_names  =  idl_new_array (tr, relational_name, 1 ) ; 
new_relation->attribute_names [0 ]  =  idl_new( tr , relational_name) ; 
new_relation->attribute_names [0 ] ->name  =  empty; 

new_relation->attribute_types  =  idl_new_array (tr, relational_name, 0) ; 

new_relation->tuples  =  idl_empty_linked ( tr, relational_tuple) ; 

new_relation->tuple_type  =  NULL; 

new_relation->key  =  empty; 

/*  set  global  pointer  to  new  relation  so  that  the  attributes  of  the  new 
relation  may  be  initialized  by  the  user.  Note:  that  dpy_active  does 
not  allow  other  parameters  to  be  passed,  thus  a  global  pointer  is  used 
so  that  init_rel_screen  can  access  the  new  relation  */ 

init_relation  =  new_relation; 
dpy_active ( init_rel_screen, 0L) ; 

/*  if  a  write  transaction  is  open,  then  add  the  new  relation  to  the  database  */ 
if  (is_writable) 

idl_insert_back ( r el at ional_relat ion, database- >rel at  ions , new_relation) ; 
} 
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/***************************************************************************** 

* 

*  Class  relation  methods 
* 

*  relation_key 

*  relation_print 

*  create_tuple 

*  ck_union_compatability 
* 

*  union_op 

*  cart_prod_op 

*  set_diff_op 

*  project_op 

*  select_op 
* 
*****************************************************************************/ 

******************************************************************************** 

Class  Relation  Methods 
******************************************************************************** 

/*  Displays  a  short  description  of  a  relation  */ 

idl_routine  void  relation_key (relation) 

relational_relation  relation; 
{ 

idl_univ  u; 

if  (idl_string_size ( relation->relation_name)  ==  0) 
{ 

dpy_cstring ( " **  Unnamed  Relation  **"); 
} 
else 
{ 

u  =  idl_to ( idl_univ, relation->relation_name) ; 
idl_vop (u, idl_univ, idl_key, (u) ) ; 
} 
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/*  Displays  a  relation  */ 

idl_routine  void  relation_print (relation, mode) 
relational_relation  relation; 
dpy_dmode  mode; 


{ 


idl_transaction  tr  =  idl_get_trans ( relation) ; 
boolean  can_write  =  idl_trans_write_count (tr)  >  0; 
dpy_dmode  model; 

model  =  mode; 
model .embed  =  1 ; 

if  (can_write) 


{ 


} 


model. expand  =  1; 
mode. expand  =  1; 


if  (model .expand  >  1) 
{ 

idl_top (idl_any , idl_print , ( relation, mode) ) ; 
} 

dpy_attr  (  relational_relation,  relation,  relation_name,mode)  ,- 

dpy_eol ( )  ; 

dpy_spacey (2L) ; 

dpy_eol ( ) ; 

dpy_attr ( relational_relation, relation, tuples, model ) ; 

dpy_eol ( ) ;     . 

if  (can_write)  /*  Don't  want  to  display  all  of  these  attributes  unless 

there  is  a  transaction  open  which  allows  writing  to  the 
database.  This  information  is  needed  for  the  implementation 
of  the  R/OODBMS  but  is  not  needed  by  the  user.  However, 
these  attributes  must  be  assigned  appropriate  values  if 
the  relational  algebra  operations  of  the  system  are  to 
function  properly.  */ 
{ 

dpy_spacey (2L) ; 

dpy_eol ( ) ; 

dpy_attr ( relational_relation, relation, attribute_names , model ) ; 

dpy_eol ( ) ; 

dpy_spacey ( 2  L ) ; 

dpy_eol ( ) ; 

dpy_attr ( relational_relation, relation, attribute_types, model ) ; 

dpy_eol ( ) ; 

dpy_spacey ( 2L ) ; 

dpy_eol ( ) ; 

dpy_attr ( relational_relation, relation, tuple_type, model ) ; 

dpy_eol ( ) ; 

dpy_spacey (2L) ; 

dpy_eol ( ) ; 

dpy_attr ( relational_relation, relation, key , model ) ; 
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static  relational_tuple  init_tuple;  /*  ptr  to  new  tuple  to  be  initialized  */ 

/*  Init  action  allows  init_xxxxx_action  functions  to  exit  if  EXIT  is  selected 
in  the  pop  up  screen  for  initialization  */ 

idl_routine  void  init_action (val) 

boolean  val; 
{ 

dpy_qu  i  t ( )  ; 
} 

/*  init_tuple_screen  called  by  create_tuple .  It  allows  the  user  to  initialize 
the  attributes  of  a  new  tuple.  */ 

idl_routine  void  init_tuple_screen (a, x,y ) 

integer  a,x,y; 
{ 

dpy_dmode  mode ; 

mode  =  dpy_dmode_def ault ; 

dpy_open (" Initialize  New  Tuple" , true) ; 

dpy_open ( "New  Tuple" , true) ; 

brw_cmd( "EXIT" , "exit  initialization  screen" , init_action, OL, BRW_SCREEN) ; 

dpy_eol ( ) ; 

dpy_spacey (2L)  ; 

dpy_eol ( ) ; 

mode. expand  =  1;  /*  forces  all  attributes  to  be  displayed  */ 

/*  executes  print  method  for  relation  class/type  */ 

idl_vop ( init_tuple, relational_relation, idl_print , ( init_tuple,mode) ) ; 
dpy_close ( ) ; 

brw_input_area (y-3 , false) ; 

dpy_close ( )  ; 
dpy_boxed (x,y )  ; 


123 


/*  create_tuple  creates  and  inserts  a  new  tuple  into  a  relation.  It  calls 

tuple  method   initialize_tuple  for  the  tuple  type  of  the  current  relation. 
Each  subclass   of  tuple  must  have  a  redefinition  of  the  class  tuple's 
method  initialize_tuple .  If  there  is  no  redefinition,  then  the  function 
initialize_tuple  is   called  and  causes  an  IDL  error  to  be  raised.  */ 

idl_routine  void  create_tuple (relation) 

relational_relation  relation; 
{ 

relational_tuple  new_tuple; 

idl_transaction  tr  =  idl_get_trans ( relation) ; 

string  empty  =  idl_copy_string ( tr, " " ) ; 

boolean  is_writable  =  ( idl_trans_write_count ( tr)  >  0 )  ; 

new_tuple  =  idl_vop ( relation- >tuple_type, relational_tuple, ini tialize_tuple, 

( relation->tuple_type) ) ; 

/*  uses  global  ptr  to  new  tuple  so  it  can  be  initialized  in  function 
init_tuple_screen  */ 

init_tuple  =  new_tuple; 
dpy_active ( init_tuple_screen, OL) ; 

/*  check  to  see  if  a  write  transaction  is  open  before  inserting  the  new 
tuple  into  the  relation.  If  there  is  not  one  open,  then  the  new  tuple 
is  lost  */ 

if  (is_writable) 

idl_insert_back (relational_tuple, relation-> tuples, new_tuple) ; 

} 
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/*  ck_union_compatability  Cakes  two  relations  and  determines  if  they  are  union 
compatible.  This  means  that  the  two  relations  have  the  same  number 
of  attributes  and  that  the  corresponding  attribute  types  are  the  same  - 
in  the  same  order.  That  is,  they  are  the  of  the  same  order  and 
Rl_attr(i)  =  R2_attr(i)  for  1  less  than  or  equal  to  i  and  i  less 
than  or  equal  to  n.  */ 

idl_routine  boolean  ck_union_compatability (ptr_Rl , ptr_R2 ) 
relational_relation  ptr_Rl ,ptr_R2 ; 

{ 

boolean  same_order, types_equal ; 

idl_transaction  tr; 

integer  Rl_degree,R2_degree, i ,Rl_types, R2_types; 

tr  =  idl_get_trans (ptr_Rl) ; 
types_equal  =  true; 

Rl_degree  =  idl_array_size (ptr_Rl->attribute_names) ; 
R2_degree  =  idl_array_size (ptr_R2->attribute_names) ; 
Rl_types  =  idl_array_size (ptr_Rl->attribute_types) ; 
R2_types  =  idl_array_size (ptr_R2->attribute_types) ; 

/*  check  to  make  sure  attribute  types  have  legal  values  */ 
if  ((Rl_types  ==  0)  &&  (R2_types  ==  0)) 
idl_raise ( IDL_ERROR , 

"Both  Rl  and  R2  have  illegal  values  for  their  attribute_types 
attributes! " ) ; 
else 
{ 

if  (Rl_types  ==  0) 
idl_raise ( IDL_ERROR, 

"Rl  has  an  illegal  value  for  its  attribute_types  attribute!"); 

if  (R2_types  =  =  0) 
idl_raise ( IDL_ERROR, 

"R2  has  an  illegal  value  for  its  attribute_types  attribute!"); 
} 

/*  check  to  make  sure  attribute  names  have  legal  values  */ 
if  {{Rl_degree  ==  0)  &&  (R2_degree  ==  0)) 
idl_raise(IDL_ERROR, 

"Both  Rl  and  R2  have  illegal  values  \nfor  their  attribute_names 
attributes !  " )  ; 
else 
{ 

if  (Rl_degree  ==  0) 
idl_raise(IDL_ERROR, 

"Rl  has  an  illegal  value  for  \nits  attribute_names  attribute!"); 

if  (R2_degree  ==  0) 
idl_raise ( IDL_ERROR, 

"R2  has  an  illegal  value  for  \nits  attribute_names  attribute!"); 
} 

/*  check  the  order  of  each  relation  */ 
same_order  =  (Rl_degree  ==  R2_degree) ; 

/*  each  attribute  must  be  of  some  type.  Thus,  there  must  be  the  same  number  of 
of  elements  in  the  attribute_names  array  as  there  are  in  the  attribute_types 
array.  */ 

if  ((Rl_degree  !=  Rl_types)  &&  (R2_degree  !=  R2_types)) 
idl_raise(IDL_ERROR, 

"Neither  Rl  and  R2  have  the  a  one-to-one  correspondence\nbetween  the 
number  of  attributes  and  types  listed  in  their\nattribute_names  and 
attribute_types  attibutes ! " ) ; 

else 
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{ 

if  (Rl_degree  !=  Rl_types) 
idl_raise(IDL_ERROR, 

"Rl  does  not  have  a  one-to-one  correspondence\nbetween  its 
nattribute_names  and  attribute_types  attibutes!"); 

if  (R2_degree  !=  R2_types) 
idl_raise(IDL_ERROR, 

"R2  does  not  have  a  one-to-one  correspondence\nbetween  its 
nattribute_names  and  attribute_types  attibutes!"); 
} 

if  (same_order) 
{ 

/*  check  the  corresponding  types  of  each  */ 
for  (i  =  0;  i  <  R2_degree;  ++i) 
{ 

types_equal  =  ( (strcmp (ptr_Rl->attribute_types [i] ->name, 

ptr_R2->attribute_types [ i ] ->name) )  ==  0); 
if  ( ! types_equal ) 
break; 
} 
) 

if  (same_order  &&  types_equal) 
{ 

return  true;  /*  the  two  relations  are  union  compatable  */ 
} 
else 
{ 

if  ( ! same_order ) 

idl_rai  se ( IDL_ERROR , 

"The-  two  relations  are  not  union  compatible! \nThey  are  not  of 
the  same  order."); 
else 

idl_raise (IDL_ERROR, 

"The  two  relations  are  not  union  compatible ! \nThey  do  not  have 
equal  corresponding  types."); 

return  false; 
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char  *R1, *R2, *R3;  /*  global  ptrs  to  the  parameters  for  the  union  operation. 

Rl  union  R2  */ 

/*  union_parse_action  is  called  by  the  brw_input  operation  within  the  union_op 
function.  Union  parse  action  takes  the  query  string  and  parses  it  into  the 
two  operand  relations  Rl  and  R2 .  */ 

static  void  uni on_parse_act ion (query ) 

char*  query; 
{ 

char  *Rl_ptr, *char_ptr; 

integer  size, i ; 

boolean  done  =  false; 

char_ptr   =   query; 

/*  allocate  room  for  parse  of  the  union  op  parameters 

Rl  will  hold  the  first  parameter  and  R2  the  second  */ 
size  =  strlen (query ) ; 

Rl  =  (char* ) calloc ( (size+1 ), sizeof (char) ) ; 
R2  =  (char*) calloc ( (size+1 ), sizeof (char) ) ; 

Rl_ptr   =   Rl; 
char_ptr   =   query; 

/*  note:  if  size  gets  decremented  all  the  way  to  zero,  then  there  is  a 
problem  with  the  query  because  the  delimeter  '  union  '  could  not  be 
found  */ 
while  (!done  &&  size  >  0) 
{ 

if  (*char_ptr  !=  '  ')  /*  if  not  a  space  copy  the  char  into  Rl  */ 
{ 

*Rl_ptr=*char_ptr ; 
+  +char__ptr; 
++Rl_ptr; 
--size; 
} 
else  /*  we  may  have  hit  the  delimeter  for  the  first  parameter  */ 
{ 

/*  check  to  see  if  next  char  is  a  "u"  -  the  first  letter  of  union 

which  is  the  delimeter  between  the  two  parameters  */ 
if  (strncmp (char_ptr, "  union  ",!)    ==  0)  /*  then  it  is  union  sentinal  */ 
{ 

for  (i  =0;  i  <  7;++i)  /*  jump  past  the  delimeter  */ 
{ 

++char_ptr; 
--size; 
} 
strcpy (R2 , char_ptr) ;  /*  copy  second  parameter  into  R2  */ 
done=true; 
} 
else  /*  the  space  is  part  of  the  first  parameter,  so  put  in  Rl  */ 
{ 

/*  space  is  part  of  first  relation  name  so  keep  it  */ 
*Rl_ptr=*char_ptr; 
++char_ptr; 
++Rl_ptr; 
--size; 
} 
} 
} 

if  (size  !=  0)  /*  size  only  =  0  if  union  was  not  found  in  the  query  */ 

NULL  ; 
else 

idl_raise(IDL_ERROR, 

"There  is  an  error  in  your  union  query!  Try  Again."); 
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/*  init_temp_rel  is  called  by  union_op,  set_diff_op  and  select_op  since  they 
are  the  three  simple  relational  algebra  operations  that  have  a  resultant 
relation  that  is  of  the  same  structure  as  the  operand  relations.  Init  temp 
rel  creates  a  new  relation  that  is  to  be  the  resultant  relation  of  one  of 
the  three  listed  operations.  It  assigns  default  values  and  then  passes  a 
reference  to  the  new  relation  to  the  caller.  */ 

idl_routine  relational_relation  init_temp_rel (ptr_Rl , ptr_R2 ) 
relational_relation  ptr_Rl ,ptr_R2 ; 

{ 

relational_relation  temp_relation; 
static  integer  temp_rel_num  =  0; 
idl_transaction  tr; 
string  temp_rel_name; 
char  temp_name [80 ] ; 
integer  degree  =  0 ,  i ; 

tr  =  idl_get_trans (ptr_Rl ) ; 

degree  =  idl_array_size (ptr_Rl->attribute_names) ; 

temp_relation  =  idl_new ( tr, relational_relation) ;  /*  must  still  assign 

legal  values  */ 

/*  set  up  a  unique  name  for  resultant  relation  */ 
sprintf (temp_name, "%ldTEMP_%c%c . %c%c" , 

+  + 1  emp_re l_num , 

ptr_Rl->relation_name [0 ] , 

ptr_Rl->relation_name [1 ] , 

ptr_R2->relation_name [0 ] , 

ptr_R2->relation_name [1 ] ) ; 
temp_rel_name  =  idl_copy_string ( tr, temp_name) ; 

temp_relation->relation_name  =  temp_rel_name; 
temp_relation->attribute_names  =  idl_new_array ( tr, relational_name, degree) ; 

/*  assign  default  values  for  attribute  names  to  be  the  same  as  those  in 

Rl  relation  */ 
for  (  i=0;  i<degree;  ++i) 
{ 

temp_relation->attribute_names [ i ]  =  ptr_Rl->attribute_names [i ] ; 
} 

temp_relation->attribute_types  =  ptr_Rl->attribute_types; 

temp_relation->tuples  =  idl_empty_l inked ( tr , relational_tuple) ; 

/*  assign  a  default  tuple  type  that  is  the  same  as  the  first  relations  */ 
temp_relation->tuple_type  =  ptr_Rl->tuple_type; 

/*  default  key  is  the  key  of  relation  Rl  */ 
temp_relation->key  =  ptr_Rl->key; 


} 


return  temp_relation; 
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/*  report_union_error  reports  errors  as  the  name  implies.  It  was  taken  out 
of  union_op  and  made  into  a  separate  function  to  make  union_op  more 
readable.  This  has  also  been  done  with  the  other  four  operations  in 
the  R/OODBMS.  */ 

void  report_union_error ( f oundl , f ound2 ) 

boolean  f oundl , found2 ; 
( 

if  ( ! f oundl  &&  ! found2) 

{ 

idl_raise(IDL_ERROR, 

"Neither  relation  is  in  this  database!"); 
} 
else 
{ 

if  (Ifoundl) 
{ 

idl_raise (IDL_ERROR, 

"Rl  (the  first  parameter)  is  not  in  this  database!"); 
} 
if  (!found2) 
{ 

idl_rai  se ( I DL_ERROR , 

"R2  (the  second  parameter)  is  not  in  this  database!"); 
} 
} 
if  (f oundl  &&  found2) 
{ 

idl_raise(IDL_ERROR; 

"A  SERIOUS  ERROR  HAS  OCCURED  IN  THE  UNION  OPERATION!"); 
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/*  union_op  is  executed  when  Union  is  selected  within  the  browser.  The 
syntax  for  the  operation  allows  the  user  to  input  the  two  relations 
to  be  unioned  and  then  creates  the  resultant  relation  (with  an  assigned 
default  name).  It  calls  union_parse_action,  init_temp_rel , 
check_union__coinpatability  and  report_union_error .  */ 

******************************************************************************** 

Union  Method 

******************************************************************************** 

idl_routine  void  union_op (relation) 
relational_relation  relation; 

{ 

relational_relation  ptr_Rl, ptr_R2 , temp_relation; 

relational_database  database; 

idl_trans_mode  tmode; 

idl_univ  root; 

string  parameterl ,parameter2 ;   /*  references  to  the  parameters  Rl  and  R2  */ 

static  integer  temp_rel_num  =  0, index  =  0; 

idl_transaction  tr; 

boolean  f oundl , found2 , is_writable  =  false, duplicate  =  true, compatible  =  false; 

tr  =  idl_get_trans ( relation) ; 

tmode  =  idl_trans_mode_def ault ; 

root  =  idl_trans_get_root ( tr)  ; 

database  =  idl_to  (relational_database,  root)  ,- 

foundl  =  false; 

found2  =  false; 

is_writable  =  ( idl_trans_write_count ( tr )  >  0); 

brw_input ("Union  Query", 

"Please  input  the  union  query  (Rl  union  R2) :  ", 
0L,0L,0L, false, 
union_parse_action) ; 

/*  copy  the  C  strings  Rl  and  R2  into  IDL  strings  */ 
parameterl  =  idl_copy_string ( tr , Rl ) ; 
parameter2  =  idl_copy_string ( tr , R2 ) ; 

/*  search  the  database  for  the  two  relations:  Rl  and  R2  */ 
idl_linked_for  (relational_relation,database->relations, rel ) 
{ 

if  (strcmp  (rel->relation_name, parameterl )  ==  0)  /*  found  relation  1  */ 
{ 

ptr_Rl  =  rel;  /*  point  at  relation  1  */ 
foundl  =  true; 
} 

if  (strcmp  (rel->relation_name, parameter2 )  ==  0)  /*  found  relation  2  */ 
{ 

ptr_R2  =  rel; 
found2  =  true; 
} 
)  idl_end_for 

if  (foundl  ScSc    found2) 
{ 

/*  check  for  union  compatability  */ 

compatible  =  idl_vop (ptr_Rl , relational_relation, check_union_compatability , 

(ptr_Rl,ptr_R2) ) ; 

if  (compatible) 
{ 

temp_relation  =  ini t_temp_rel (ptr_Rl, ptr_R2 ) ; 

/*  insert  the  tuples  from  Rl  and  R2  into  Temp  relation.  First 


130 


all  the  tuples  from  Rl  are  inserted  into  Temp  relation.  */ 

idl_linked_for  (relational_tuple, ptr_Rl -> tuples, tuple) 

{ 

idl_insert_back (relational_tuple, temp_relation->tuples, tuple) ; 
}  idl_end_for 

/*  don't  insert  any  duplicate  tuples  into  the  resultant  relation. 
Thus,  have  to  check  the  tuple  key  with  each  tuple  already  in  the 
result  (or  in  Rl )  before  entering  another  tuple  into  the 
resultant  relation  */ 

idl_linked_for  ( rel at ional_tuple, ptr_R2-> tuples, r2_tuple) 
{ 

idl_linked_for  ( relational_tuple, ptr_Rl-> tuples , rl_tuple) 
{ 

/*  duplicate  check  takes  the  two  tuples  and 

determines  if  they  have  the  same  attribute  values.  If  yes, 
then  they  are  duplicates.  It  returns  a  boolean.  */ 

duplicate  =  idl_vop (rl_tuple, relational_tuple, equal_to, 

( rl_tuple, r2_tuple, index) ) ; 

if  (duplicate) 
{ 

break; 

/*  get  out  of  loop  cuz  found  tuple  was  a  duplicate  */ 
} 
}  idl_end_for 

if  ( ! duplicate) 
{ 

idl_insert_back (relational_tuple, 

temp_relation->tuples , r2_tuple) ; 
} 
}  idl_end_for 

/*  If  a  write  transaction  is  open  when  this  command  is  executed  then 
if  it  becomes  committed  the  temp  relation  will  be  written  to  the 
database.  However,  if  a  read  or  examine  transaction  is  open,  then 
the  temp  relation  will  be  in  the  database  in  memory  but  will  not 
be  written  back  to  secondary  storage.  */ 

idl_insert_back (relational_relation,database->relations , 
temp_relation) ; 
} 
else  /*  else  part  of  if  (compatible)*/ 
{ 

idl_raise(IDL_ERROR, 

"The  two  relations  are  not  union  compatible!"); 
) 
} 
else  /*  else  part  of  if  ( f oundl  &&  f ound2 )  */ 
{ 

report_union_error ( f oundl , f ound2 ) ; 
} 
} 
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/*  dif f erence_parse_action  is  called  by  Che  brw_input  operation  within  the 
set_diff_op  function.  Difference  parse  action  takes  the  query  string  and 
parses  it  into  the  two  operand  relations  Rl  and  R2 .  */ 

static  void  dif ference_parse_action (query  ) 

char*  query; 
{ 

char  *Rl_ptr, *char_ptr; 

integer  size,  i  ; 

boolean  done  =  false; 

char_ptr  =  query; 

/*  allocate  room  for  parse  of  the  union  op  parameters 

Rl  will  hold  the  first  parameter  and  R2  the  second  */ 
size  =  strlen (query ) ; 

Rl  =  (char* ) calloc ( (size+1) , sizeof (char)  )  ; 
R2  =  (char* ) calloc ( (size+1 ), sizeof (char) ) ; 

Rl_ptr  =  Rl; 

/*  do  the  parse  */ 
char_ptr  =  query; 

/*  note:  if  size  gets  decremented  all  the  way  to  zero,  then  there  is  a 
problem  with  the  query  because  the  delimeter  '  union  '  could  not  be 
found  */ 
while  ( ! done  &&  size  >  0) 
{ 

if  (*char_ptr  !  =  '  ')  /*  if  not  a  space  copy  the  char  into  Rl  */ 

*Rl_ptr=*char_ptr; 
++char_ptr; 
++Rl_ptr; 
--size; 
} 
else  /*  we  may  have  hit  the  delimeter  for  the  first  parameter  */ 
{ 

/*  check  to  see  if  next  char  is  a  "-"  which  is  the  delimeter  between 
the  two  parameters  */ 
if  (strncmp (char_ptr, "  -  ",3)  ==  0)  /*  then  it  is  difference  sentinal  */ 
{ 

for  (i  =0;  i  <  3;++i)  /*  jump  past  the  delimeter  */ 
{ 

++char_ptr; 
--size; 
} 
strcpy (R2 ,char_ptr) ;  /*  copy  second  parameter  into  R2  */ 
done=true; 
} 
else  /*  the  space  is  part  of  the  first  parameter,  so  put  in  Rl  */ 
{ 

/*  space  is  part  of  first  relation  name  so  keep  it  */ 
*Rl_ptr=*char_ptr; 
++char_ptr; 
++Rl_ptr; 
--size; 
} 
} 
} 

if  (size  !=  0)  /*  size  only  =  0  if  union  was  not  found  in  the  query*/ 

NULL; 
else 

idl_raise(IDL_ERROR, 

"There  is  an  error  in  your  difference  query!  Try  Again."); 
} 
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/*  report_dif ference_error  reports  errors  as  the  name  implies.  It  was  taken  out 
of  set_diff_op  and  made  into  a  separate  function  to  make  set_diff_op  more 
readable.  This  has  also  been  done  with  the  other  four  operations  in 
the  R/OODBMS.  */ 

void  report_dif f erence_error ( f oundl , f ound2 ) 

boolean  f oundl , found2 ; 
{ 

if  (! f oundl  &&  !found2) 
{ 

idl_raise(IDL_ERROR, 

"Neither  relation  is  in  this  database!"); 
} 
else 
{ 

if  (Ifoundl) 
{ 

idl_raise(IDL_ERROR, 

"Rl  (the  first  parameter)  is  not  in  this  database!"); 
} 
if  (!found2) 
{ 

idl_raise ( IDL_ERROR, 

"R2  (the  second  parameter)  is  not  in  this  database!"); 
} 
} 
if  (f oundl  &&  found2) 
{ 

idl_raise(IDL_ERROR, 

"A  SERIOUS  ERROR  HAS  OCCURED  IN  THE  DIFFERENCE  OPERATION!"); 
} 
} 
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/*  set_diff_op  is  executed  when  Difference  is  selected  within  the  browser. 
The  syntax  for  the  operation  allows  the  user  to  input  the  two  relations 
to  be  operated  on  and  then  creates  the  resultant  relation.  It  calls 
dif ference_parse_action,  init_temp_rel ,  check_union_compatability 
and  report_dif ference_error .  */ 

***************************************************************************** 

Difference  Method 

******************************************************************************** 

idl_routine  void  set_di ff_op ( relation) 
relational_relation  relation; 

{ 

relational_relation  ptr_Rl , ptr_R2 , temp_relation; 

relational_database  database; 

idl_trans_mode  tmode; 

idl_univ  root; 

string  parameterl , parameter2 ;   /*  references  to  the  parameters  Rl  and  R2  */ 

static  integer  temp_rel_num  =  0, index  =  0; 

idl_transaction  tr; 

boolean  f oundl, f ound2 , is_writable  =  false, duplicate  =  true, compatible  =  false; 

tr  =  idl_get_trans (relation) ; 
tmode  =  idl_trans_mode_de fault ; 
root  =  idl_trans_get_root ( tr) ; 
database  =  idl_to (relational_database, root ) ; 
' foundl  =  false; 
found2  =  false; 
is_writable  =  (idl_trans_write_count ( tr)  >  0); 

brw_input ( "Dif f erence  Query", 

"Please  input  the  Difference  query  (Rl  -  R2 ) :  ", 

0L, 0L,0L, false, 

dif ference_parse_action) ; 

/*  copy  the  C  strings  Rl  and  R2  into  IDL  strings  */ 
parameterl  =  idl_copy_string ( tr, Rl ) ; 
parameter2  =  idl_copy_string ( tr , R2 ) ; 

/*  search  the  database  for  the  two  relations:  Rl  and  R2  */ 
idl_linked_f or  (relational_relation, da t abase- >rel at ions , rel ) 
{ 

if  (strcmp  (rel->relation_name, parameterl )  ==  0)  /*  found  relation  1  */ 
{ 

ptr_Rl  =  rel;  /*  point  at  relation  1  */ 
foundl  =  true; 
} 

if  (strcmp  (rel->relation_name, parameter2 )  ==  0)  /*  found  relation  2  */ 
{ 

ptr_R2  =  rel; 
found2  =  true; 
} 
}  idl_end_for 

if  (foundl  &&  found2) 
{ 

/*  check  for  union  compatability  */ 

compatible  =  idl_vop (ptr_Rl , relational_relation, check_union_compatability , 

(ptr_Rl,ptr_R2) ) ; 

if  (compatible) 
{ 

temp_relation  =  init_temp_rel (ptr_Rl , ptr_R2 ) ; 
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/*  don't  insert  any  tuples  from  Rl  that  are  in  R2  into  the 

resultant  relation.  Thus,  have  to  check  the  tuple  key  with  each 
tuple  in  R2  before  entering  a  tuple  into  the  resultant  relation  */ 

idl_linked_for  ( relational_tuple, ptr_Rl-> tuples , rl_tuple) 

{ 

idl_linked_for  ( relational_tuple, ptr_R2-> tuples , r2_tuple) 

{ 

/*  equal_to  takes  the  two  tuples  and  determines  if 
they  have  the  same  attribute  values.  If  yes, 
then  they  are  equal.  It  returns  a  boolean.  */ 

duplicate  =  idl_vop ( rl_tuple, relational_tuple, equal_to, 

( rl_tuple , r2_tuple, index) ) ; 

if  (duplicate)  /*  then  don't  insert  tuple  into  result  */ 
{ 

break; 

/*  get  out  of  loop  cuz  found  tuple  was  a  duplicate  */ 
) 
}  idl_end_for 

if  ( ! duplicate) 
{ 

idl_insert_back (relational_tuple, 

temp_relation->tuples, rl_tuple) ; 
} 
}  idl_end_for 

/*  If  a  write  transaction  is  open  when  this  command  is  executed  then 
if  it  becomes  committed  the  temp  relation  will  be  written  to  the 
database.  However,  if  a  read  or  examine  transaction  is  open,  then 
the  temp  relation  will  be  in  the  database  in  memory  but  will  not 
be  written  back  to  secondary  storage.  */ 

idl_insert_back (relational_relation, da t abase- >rel at ions, 
temp_relation) ; 
} 
else  /*  else  part  of  if  (compatible)*/ 
{ 

idl_raise ( IDL_ERROR, 

"The  two  relations  are  not  union  compatible!"); 
} 
} 
else  /*  else  part  of  if  (foundl  &&  found2)  */ 
{ 

report_dif f erence_error (foundl, found2 ) ; 
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/*  Cartesian_parse_action  is  called  by  the  brw_input  operation  within  the 
cart_prod_op  function.  Cartesian  parse  action  takes  the  query  string  and 
parses  it  into  the  two  operand  relations  Rl  and  R2  along  with  the  name 
of  the  resultant  relation,  R3 .  */ 

static  void  Cartesian_parse_action (query ) 
char*  query; 

{ 

char  *Rl_ptr, *char_ptr, *R3_ptr; 

integer  size, i ; 

boolean  done  =  false, delimeterl  =  false; 

char_ptr  =  query; 

/*  allocate  room  for  parse  of  the  Cartesian  product  op  parameters 

Rl  will  hold  the  first  parameter  and  R2  the  second  */ 
size  =  strlen (query ) ; 

Rl  =  (char* ) calloc ( (size+1) , sizeof (char) ) 
R2  =  (char* ) calloc ( (size+1) , sizeof (char) ) 
R3  =  (char* ) calloc ( (size+1) , sizeof (char) ) 

/*  set  pointers  to  move  along  Rl  and  R3  as  characters  are  copied  in  one 

at  a  time.  */ 
R3_ptr  =  R3; 
Rl_ptr  =  Rl; 

/*  do  the  parse  */ 
char_ptr  =  query; 

/*  note:  if  size  gets  decremented  all  the  way  to  zero,  then  there  is  a 

problem  with  the  query  because  the  delimeter  '  =  '  or  '  X  '  could  not  be 
found  */ 
while  (  !  done  &&  size,  >  0) 
{ 

if  (*char_ptr  !=  '  ')  /*  if  not  a  space  copy  the  char  into  R3  */ 
{ 

if  ( !del imeterl ) 
{ 

*R3_ptr=*char_ptr ; 
++char_ptr; 
++R3_ptr; 
--size; 
} 
else 
{ 

*Rl_ptr=*char_ptr; 
++char_ptr; 
++Rl_ptr; 
--size; 
} 
} 
else  /*  we  may  have  hit  the  a  delimeter  */ 
{ 

if  ( ! delimeterl ) 
{ 

/*  check  to  see  if  next  char  is  a  "="  -  which  separates  the 

resultant  relation  name  from  the  other  relations  in  the  query  • 
which  is  the  delimeter  between  the  first  two  parameters  */ 
if  (strncmp (char_ptr, "  =  ",3)  =-   0)  /*  then  it  is  =  sentinal  */ 
{ 

delimeterl  =  true; 

for  (i  =  0;  i  <  3;++i)  /*  jump  past  the  delimeter  */ 
{ 

++char_ptr; 
--size; 
) 
) 
else  /*  the  space  is  part  of  the  first  parameter,  so  put  in  Rl  */ 
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{ 

/*  space  is  part  of  first  relation  name  so  keep  it  */ 
*R3_ptr=*char_ptr; 
++char_ptr; 
++R3_ptr; 
--size; 
} 
} 
else 
{ 

/*  check  to  see  if  next  char  is  a  "  X  "  -  which  separates  the 
two  operands  of  the  operation  -  which  is  the  delimeter 
between  the  last  two  parameters  */ 

if  (strncmp (char_ptr, "  X  " ,  3 )  ==  0)  /*  then  it  is  X  sentinal  */ 
{ 

for  (i  =0;  i  <  3;++i)  /*  jump  past  the  delimeter  */ 
{ 

++char_ptr; 
--size; 
} 
strcpy (R2 ,char_ptr) ;  /*  copy  second  parameter  into  R2  */ 
done=true; 
} 
else  /*  the  space  is  part  of  the  first  parameter,  so  put  in  Rl  */ 
{ 

/*  space  is  part  of  first  relation  name  so  keep  it  */ 
*Rl_ptr=*char_ptr; 
++char_ptr; 
++Rl_ptr; 
--size; 
} 
} 
} 
} 

if  (size  !=  0)  /*  size  only  =  0  if  union  was  not  found  in  the  query  */ 

NULL; 
else 

idl_raise ( IDL_ERROR, "There    is   an   error   in  your   query!    Try  Again."); 
} 
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/*  report_Cart_product_error  reports  errors.  It  was  taken  out 

of  cart_prod_op  and  made  into  a  separate  function  to  make  cart_prod_op  more 
readable.  This  has  also  been  done  with  the  other  four  operations  in 
the  R/OODBMS.  */ 

void  report_Cart_product_error ( f oundl , f ound2 , f ound3 ) 
boolean  f oundl , found2 , found3 ; 

{ 

if  (! f oundl  &&  ! f ound2  &&  ! f ound3 ) 

{ 

idl_raise(IDL_ERROR, 

"None  of  the  three  relations  are  in  this  database!"); 


else 
{ 


if  (Ifoundl) 


idl_raise (IDL_ERROR, 

"Rl  is  not  in  this  database!"); 


if 


if 


if 


( ! f ound2 ) 

idl_rai  se ( IDL_ERROR , 

"R2  is  not  in  this  database!"); 

( ! found3) 

idl_raise (IDL_ERROR, 

"R3  is  not  in  this  database!"); 

(f oundl  &&  found2  &&  found3) 

idl_raise (IDL_ERROR, 

"A  SERIOUS  ERROR  HAS  OCCURED  !!!!!!  Regroup.  Try  Again."); 
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/*  cart_prod_op  is  executed  when  CartesianProduct  is  selected  within  the 
browser.  The  syntax  for  the  operation  allows  the  user  to  input  the  two 
relations  to  be  operated  on  along  with  the  name  of  the  resultant  relation. 
It  calls  Cartesian_parse_action,  report_Cart_product_error,  and 
insert_tuples.  */ 

******************************************************************************** 

Cartesian  Product  Method 

******************************************************************************** 

idl_routine  void  cart_prod_op (relation) 
relational_relation  relation; 

{ 

relational_relation  ptr_Rl, ptr_R2 ,ptr_R3 , temp_relation; 

relational_database  database; 

idl_trans_mode  tmode; 

idl_univ  root; 

string  parameterl ,parameter2, result_rel ;   /*  references  to  the  parameters 

Rl,  R2  and  R3  respectively  */ 
idl_transaction  tr; 
boolean  foundl, found2 , found3 ; 
boolean  is_writable  =  false, duplicate  =  true, compatible  =  false; 

tr  =  idl_get_trans ( relation) ; 

tmode  =  idl_trans_mode_default ; 

root  =  idl_trans_get_root (tr) ; 

database  =  idl_to (relational_database, root ) ; 

foundl  =  false; 

found2  =  false; 

found3  =  false; 

is_writable  =  ( idl_trans_write_count ( tr )  >  0); 

brw_input ( "Cartesion  Product  Query", 

"Please  input  the  Cartesian  product  query  (R3  =  Rl  X  R2 ) :  ", 
0L,0L,0L, false, 
Cartesian_parse_action) ; 

/*  copy  the  C  strings  Rl  and  R2  into  IDL  strings  */ 
parameterl  =  idl_copy_string ( tr , Rl) 
parameter2  -    idl_copy_string ( tr , R2 ) 
result_rel  =  idl_copy_string ( tr , R3 ) 

/*  don't  do  anything  if  the  resultant  relation  is  one  of  the  two  operands. 
However,  the  resultant  relation  can  be  one  that  exists  in  the  data. 
In  this  case,  the  specified  resultant  relation  will  be  over  written.  */ 

if  (!(strcmp  (result_rel, parameterl ) ==0)  && 
! (strcmp  (result_rel , parameter2 ) ==0 ) ) 


{ 


/*  search  the  database  for  the  three  relations:  Rl,  R2  and  R3  */ 
idl_linked_for  ( rel at ional_relat ion, da t abase- >relat ions, rel ) 
{ 

if  (strcmp  (rel->relation_name, parameterl)  ==  0) 
/*  found  relation  1  */ 
{ 

ptr_Rl  =  rel;  /*  point  at  relation  1  */ 
foundl  =  true; 
} 

if  (strcmp  (rel->relation_name, parameter2 )  ==  0) 
/*  found  relation  2  */ 
{ 

ptr_R2  =  rel; 
found2  =  true; 
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if  (strcmp  ( rel->relation_name, result_rel )  ==  0) 
/*  found  relation  3  */ 
{ 

ptr_R3  =  rel; 
found3  =  true; 
} 
}  idl_end_for 

if  (foundl  &&  found2  &&  found3) 
{ 

/*  perform  concatenation  of  tuples  for  Cartesian  product. 

Note,  in  this  implementation,  the  resultant  relation  already 
exists  in  the  database.  Thus,  there  is  no  need  to  insert  any 
new  relations  into  the  database.  We  only  have  to  fill  in  the 
resultant  relation  structure  that  already  exists.  */ 

ptr_R3  =  idl_vop (ptr_R3->tuple_type, relational_tuple, insert_tuples, 
(ptr_Rl,ptr_R2,ptr_R3) ) ; 

} 

else 

{ 

report_Cart_product_error ( foundl , f ound2 , f ound3 ) ; 
} 

}  /*  if  result  relation  is  one  of  operands  */ 
else 
{ 

idl_raise(IDL_ERROR, 

"R3,  the  resultant  relation  is  one  of  the  two  operand  relations . \nlt 
must  be  a  relation  in  the  database  but  not\none  of  the  two  operands!"); 

} 
} 
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char  *Attr_list;  /*  allows  global  access  to  the  attribute  list  for  the  project 

operation  */ 

/*  Project_parse_action  is  called  by  the  brw_input  operation  within  the 
project_op  function.  Project  parse  action  takes  the  query  string  and 
parses  it  into  the  single  operand  relation  Rl,  the  result  relation  R2 
along  with  the  attribute  list  that  is  to  be  projected.  */ 

static  void  Project_parse_action (query ) 

char*  query; 
{ 

char  *Rl_ptr, *char_ptr, *R2_ptr; 

integer  size, i ; 

boolean  done  =  false, delimeterl  =  false; 

charjptr   =   query; 

/*  allocate  room  for  parse  of  the  project  op  parameters 

Rl  will  hold  the  relation  being  operated  on, 

Attr_list  the  list  of  attr  to  be  projected,  and 

R2  the  resultant  relation   */ 
size  =  s trl en (query ) ; 

Rl  =  (char* ) calloc ( (size+1 ), sizeof (char) ) ;  /*  Rl  is  global  */ 
Attr_list  =  (char*) calloc ( (size+1 ), sizeof (char) ) ; 
R2  =  (char* ) calloc ( (size+1 ), sizeof (char) ) ;  /*  R2  is  global  */ 

/*  set  pointers  to  move  along  Rl  and  R2  as  characters  are  copied  in  one 

at  a  time.  */ 
R2_ptr  =  R2; 
Rl_ptr  =  Rl; 

/ *  do  the  parse  */ 
char_ptr  =  query; 

/*  note:  if  size  gets  decremented  all  the  way  to  zero,  then  there  is  a 
problem  with  the  query  because  the  delimeter  '  =  '  or  '  project  ' 
could  not  be  found  */ 
while  (!done  &&  size  >  0) 
{ 

if  (*char_ptr  !='')/*  if  not  a  space  copy  the  char  into  R2  */ 
{ 

if  ( ! delimeterl ) 
{ 

*R2_ptr=*char_ptr; 
++char_ptr; 
++R2_ptr; 
--size; 
} 
else 
{ 

*Rl_ptr=*char_ptr; 
++char_ptr; 
++Rl_ptr; 
--size; 
) 
) 
else  /*  we  may  have  hit  a  delimeter  */ 
{ 

if  ( ! delimeterl ) 
{ 

/*  check  to  see  if  next  char  is  a  "="  -  which  separates  the 

resultant  relation  name  from  the  other  relation  in  the  query  ■ 
which  is  the  delimeter  between  the  first  two  parameters  */ 
if  (strncmp (char_ptr, "  =  ",3)  ==  0)  /*  then  it  is  =  sentinal  */ 
{ 

delimeterl  =  true; 

for  (i  =  0;  i  <  3;++i)  /*  jump  past  the  delimeter  */ 
{ 
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++char_ptr; 
--size; 
} 
} 
else  /*  the  space  is  part  of  the  first  parameter,  the  resultant 
relation  name,  so  put  in  R2  */ 
{ 

*R2_ptr=*char_ptr; 
++char_ptr; 
++R2_ptr; 
--size; 
) 
} 
else  /*  we  have  already  found  the  first  delimeter  */ 
{ 

/*  check  to  see  if  next  char  is  a  "  p  "  -  which  is 
part  of  the  delimeter  "  project  "between  the  last 
two  parameters  */ 

if  (strncmp (char_ptr, "  project  ",9)  ==  0)' 
/*  then  it  is  project  */ 
{ 

for  (i  =  0;  i  <  9;++i)  /*  jump  past  the  delimeter  */ 
C 

++char_ptr; 
--size; 
} 
strcpy (Attr_list , char_ptr) ; 

/*  copy  list  of  attributes  into  Attr_list  and  now  parse  the 
list  of  attributes  */ 

done=true; 
} 
else  /*  the  space  is  part  of  the' first  parameter,  so  put  in  Rl  */ 
{ 

/*  space  is  part  of  first  relation  name  so  keep  it  */ 

*Rl_ptr=*char_ptr; 

++char_ptr; 

++Rl_ptr; 

--size; 


} 

if  (size  !=  0)  /*  size  only  =  0  if  union  was  not  found  in  the  query  */ 

NULL; 
else 

idl_raise (IDL_ERROR, "There   is   an  error   in  your  query!    Try  Again."); 
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/*  report_project_error  reports  errors.  It  was  taken  out 

of  project_op  and  made  into  a  separate  function  to  make  project_op  more 
readable.  This  has  also  been  done  with  the  other  four  operations  in 
the  R/OODBMS.  */ 

void  report_project_error (f oundl, found2 , attr_found) 

boolean  f oundl ,  f ound2 ,  attr_found; 
{ 

if  (!  f oundl  ScSc    !found2) 

{ 

idl_raise(IDL_ERROR, 

"Neither  of  the  two  relations  are  in  this  database!"); 
} 
else 


if  ( !attr_found) 

idl_raise ( IDL_ERROR, 

"All  of  the  attributes  in  the  attribute  list  \nare  not  in  Rl! 


if 


if 


if 


(  ! f oundl) 

idl_raise ( IDL_ERROR, 

"Rl  is  not  in  this  database!"); 

(  ! found2) 

idl_raise(IDL_ERROR, 

"R2  is  not  in  this  database!"); 


[i oundl  &&  found2) 

idl_raise(IDL_ERROR, 

"A  SERIOUS  ERROR  HAS  OCCURED  !!!!!!  Regroup.  Try  Again.") 
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/*  project_op  is  executed  when  Projection  is  selected  within  the 

browser.  The  syntax  for  the  operation  allows  the  user  to  input  the  single 
relation  to  be  operated  on  along  with  the  name  of  the  resultant  relation  and 
the  attribute  list  to  be  projected.  It  calls  Pro ject_parse_action, 
report_project_error,  and  insert_f ields .  */ 

******************************************************************************** 

Project  Method 

******************************************************************************** 

idl_routine  void  project_op (relation) 
relational_relation  relation; 

{ 

relational_relation  ptr_Rl, ptr_Attr_list,ptr_R2 , temp_relation; 

relational_database  database; 

idl_trans_mode  tmode; 

idl_univ  root; 

string  parameterl , att r_st ring, resul t_rel ;   /*  references  to  the  parameters 

Rl,  attr  list  and  result 
relation   respectively  */ 

idl_transaction  tr; 

boolean  f oundl , f ound2 ,done, attr_f ound; 

boolean  is_writable  =  false, duplicate  =  true, compatible  =  false; 

char  *attr_ptr, *delimeter  =  ",";  /*  delimeter  between  elements 

in  attribute  list  */ 

string  *attr_list [100 ] ; 

integer  i=l , count, size, index, index_array [100] , ii=0; 

idl_linked_elem (relational_tuple)'  result_tuple; 

tr  =  idl_get_trans (relation) ; 

tmode  =  idl_trans_mode_de fault ; 

root  =  idl_trans_get_root ( tr) ; 

database  =  idl_to (relational_database, root)  ; 

foundl  =  false; 

found2  =  false; 

done  =  false; 

is_writable  =  ( idl_trans_write_count ( tr)  >  0 ) ; 

brw_input ("Project  Query", 

"Please  input  the  Project  query  (R2  =  Rl  project  Attr_list):  ", 
0L, 0L,0L, false, 
Project_parse_action)  ; 

/*  copy  the  C  strings  Rl,  R2  and  Attr_list  into  IDL  strings  */ 
parameterl  =  idl_copy_string ( tr, Rl) ; 
result_rel  =  idl_copy_string ( tr, R2 ) ; 
attr_string  =  idl_copy_string (tr, Attr_list ) ; 

/*  parse  tokens  in  attribute  string  */ 

if  ( (attr_ptr  -   strtok (attr_string, delimeter) )  ==  NULL) 
{ 

/*  error,  no  token  */ 

idl_rai  se ( I DL_ERROR , 

"You  did  not  list  any  attribute/field  names  in\nyour  project  query! 
Try  again,  meathead!"); 
) 
else 
{ 

attr_list[0]  =  idl_new_string (tr, 80) ; 
attr_list[0]  =  idl_copy_string( tr, attr_ptr) ; 
) 
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while  ( (attr_ptr  =  strtok (NULL, delimeter) )  !=  NULL) 

{ 

attr_list [i ]  =  idl_new_string ( tr, 80 ) ; 

attr_list [i ]  =  idl_copy_string( tr, attr_ptr) ; 

+  +  i ; 
} 

/*  don't  do  anything  if  the  resultant  relation  is  the  operand  relation. 
However,  the  resultant  relation  can  be  one  that  exists  in  the  data. 
In  this  case,  the  specified  resultant  relation  will  be  over  written.  */ 

if  (!(strcmp  (result_rel, parameterl ) ==0) ) 
{ 

/*  search  the  database  for  the  two  relations:  Rl  and  R2  */ 
idl_linked_f or  (relational_relation, database->relations, rel ) 
{ 

if  (strcmp  (rel->relation_name, parameterl )  ==  0) 
/*  found  relation  1  */ 
( 

ptr_Rl  =  rel;  /*  point  at  relation  1  */ 
foundl  =  true; 
} 

if  (strcmp  (rel->relation_name, result_rel )  ==  0) 
/*  found  relation  2  */ 
{ 

ptr_R2  =  rel; 
found2  =  true; 
} 
}  idl_end_for 

count  -    i;  /*  count  is  the  number  of  tokens  -  1  */ 

/*  check  each  attr  name  in  the  attr  list  of  the  project  operation  to 
ensure  that  the  field  exists  in  the  relation  Rl  */ 

for (i=0 ; i<count ; ++i ) 
{ 

attr_found  =  false; 
ii  =  0; 

idl_array_f or ( relational_name, ptr_Rl->attribute_names , aname) 
{ 

ii++;  /*  position  in  attribute  list  */ 

if  (strcmp  (aname->name, attr_list [i ] )  ==  0)  /*  attr  name  in  attr 

list  is  a  field 
of  Rl  */ 
{ 

attr_found  =  true; 
index_array [i ] =ii; 
break; 
} 
}  idl_end_for 

if  ( !attr_found) 
{ 

break;  /*  an  attr  in  the  project  attr  list  is  not 
in  the  relation  Rl .  Thus,  the  operation 
cannot  be  performed  */ 
} 
} 

if  (foundl  &&  found2  &&  attr_found) 
{ 

/*  everything  is  ok,  perform  projection  operation  on  relation  Rl . 
Note,  in  this  implementation,  the  resultant  relation  already 
exists  in  the  database.  Thus,  there  is  no  need  to  insert  any 
new  relations  into  the  database.  We  only  have  to  fill  in  the 
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resultant  relation  structure  that  already  exists.  */ 

/*  iterate  through  every  tuple  of  Rl  and  copying  only  the  desired 
fields  into  R2 .  Note:  Rl  and  R2  will  have  the  same  number  of 
tuples  but  the  relations  will  be  of  differing  degree.  */ 

ptr_R2  =  idl_vop (ptr_R2->tuple_type, relational_tuple, insert_f ields, 
(ptr_Rl,ptr_R2) ) ; 

} 

else 

{ 

report_project_error (foundl , f ound2 , attr_f ound) ; 
} 
} 
else  /*  end  of  if  (!(strcmp  ( result_rel ,parameterl ) ==0 ) )  */ 
{ 

idl_raise (IDL_ERROR, 

"R2,  the  resultant  relation  is  also  the  operand. \nlt  must  be  a 
relation  in  the  database  but  not  the  operand!"); 
} 

} 
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char  *Attr, *Obj , *Comp_opr ;  /*  allows  global  access  to  three  stings:  an  attribute 

name  used  for  the  select  condition,  the  name  of 
the  object  created  that  contains  the  select  values 
for  comparison,  and  the  comparison  operator  name.  */ 

/*  Select_parse_action  is  called  by  the  brw_input  operation  within  the 
select_op  function.  Select  parse  action  takes  the  query  string  and 
parses  it  into  the  single  operand  relation  Rl,  the  attribute  that  is 
going  to  be  used  to  select  upon,  the  comparison  operator  to  be  used, 
and  the  name  of  the  object  that  contains  the  attribute  value  to  be 
compared  with.*/ 

static  void  Select_parse_action (query ) 

char*  query; 
{ 

char  *Rl_ptr, *char_ptr, *Attr_ptr, *Comp_opr_ptr; 

integer  size, i; 

boolean  done  =  false, delimeterl  =  false; 

char_ptr   =   query; 

/*  allocate  room  for  parse  of  the  select  op  parameters 
Rl  will  hold  the  relation  being  operated  on, 
Attr  the  attr  that  selection  will  be  made  on, 
Comp_opr  the  comparison  operator  (=,<,>),  and 
Obj  holds  the  values  to  be  compared  with  */ 

size  =  strlen (query ) ; 

Rl  =  (char* ) calloc ( (size+1) , sizeof (char) ) ;  /*  Rl  is  global  */ 
Attr  =  (char* ) calloc ( (size+1) , sizeof (char )) ;  /*  Attr  is  global  */ 
Obj  =  (char* ) calloc ( (size+1 ), sizeof (char) ) ;  /*  Obj  is  global  */ 
Comp_opr  =  (char* ) calloc ( (size+1) , sizeof (char) ) ;  /*  Comparison  Operator 

is  global  */ 

/*  set  pointers  to  move  along  Rl  and  Obj  as  characters  are  copied  in  one 

at  a  time.  */ 
Attr_ptr  =  Attr; 
Rl_ptr  =  Rl; 
Comp_opr_ptr  =  Comp_opr; 

/*  do  the  parse  */ 
char_ptr  =  query; 

/*  note:  if  size  gets  decremented  all  the  way  to  zero,  then  there  is  a 
problem  with  the  query  because  the  delimeter  '  select  ' 
could  not  be  found  */ 
while  (!done  &&  size  >  0) 
{ 

if  (*char_ptr  !=  '  ')  /*  if  not  a  space  copy  the  char  into  Rl  */ 


{ 


if  ( ! delimeterl ) 
{ 

*Rl_ptr=*char_ptr; 
++char_ptr; 
++Rl_ptr; 
--size; 


else 
{ 


*Attr_ptr=*char_ptr; 
++char_ptr; 
++Attr_ptr; 
--size; 


else  /*  we  may  have  hit  a  delimeter  */ 
{ 

if  ( ! delimeterl ) 
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{ 

/*  check  to  see  if  next  char  is  a  "select"  - 

which  is  the  delimeter  between  the  first  two  parameters  */ 
if  (strncmp (char_ptr, "  select  "  ,  8 )  ==  0)  /*  then  it  is  select  */ 
{ 

delimeterl  =  true; 

for  (i  =0;  i  <  8;++i)  /*  jump  past  the  delimeter  */ 
{ 

++char_ptr; 
--size; 
} 
} 
else  /*  the  space  is  part  of  the  first  parameter,  the  operand 
relation  name,  so  put  in  Rl  */ 
{ 

*Rl_ptr=*char_ptr ; 
++char_ptr; 
++Rl_ptr; 
--size; 
} 
} 
else  /*  we  have  already  found  the  first  delimeter  */ 
{ 

/*  check  to  see  if  the  next  token  is  a  comparison  operator  */ 

if  (strncmp (char_ptr, "  =  ",3)  ==  0  II 
strncmp (char_ptr, "  <  ",3)  ==  0  II 
strncmp (c ha r_ptr, "  >  ",3)  ==0) 
{ 

+  +  c  ha  r_p  t  r  ; 
--size; 

for  (i  =0;  i  <  l;++i)  /*  copy  comparison  operator  */ 
{  • 

*Comp_opr_ptr=*char_ptr; 
++Comp_opr_ptr; 
++char_ptr; 
--size; 
} 
++char_ptr; 
--size; 

strcpy (Obj , char_ptr) ; 
done=true; 
} 
else  if  (strncmp (char_ptr, "  /=  ",4)  ==011 
strncmp (char_ptr, "  <=  ",4)  ==  0  I  I 
strncmp (char_ptr, "  >=  ",4)  ==  0) 
{ 

++char_ptr; 
--size; 

for  (i  =0;  i  <  2;++i)  /*  copy  comparison  operator  */ 
{ 

*Comp_opr_ptr=*char_ptr; 
++Comp_opr_ptr; 
++char_ptr; 
-  -  s  i  z  e  ; 
} 
++char_ptr; 
--size; 

strcpy (Obj , char_ptr)  ; 
done=true; 
} 
else  /*  the  space  is  part  of  the  first  parameter,  so  put  in  Rl  */ 
{ 

/*  space  is  part  of  first  relation  name  so  keep  it  */ 

*Attr_ptr=*char_ptr; 

++char_ptr; 

++Attr_ptr; 

--size; 
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} 
} 
} 

} 

if  (size  !=  0)  /*  size  only  =  0  if  union  was  not  found  in  the  query  */ 

NULL; 
else 

idl_raise (IDL_ERROR, "There   is   an   error   in  your   query!    Try   Again."); 


149 


/*  report_select_error  reports  errors.  It  was  taken  out 

of  select_op  and  made  into  a  separate  function  to  make  select_op  more 
readable.  This  has  also  been  done  with  the  other  four  operations  in 
the  R/OODBMS.  */ 


void  report_select_error ( f oundl , f ound2 , attr_f ound) 
boolean  f oundl ,  f ound2 ,  attr_found; 

{ 

if  ( ! f oundl  &&  !found2) 

{ 

idl_raise(IDL_ERROR, 

"Neither  of  the  two  relations  are  in  this  database!"); 


} 
else 

{ 


if  ( !attr_found) 

idl_raise (IDL_ERROR, 

"The  attribute  specified  for  comparison  is  not  in  Rl!"); 


if 


if 


if 


( ! f oundl) 

idl_rai  se ( I DL_ERROR , 

"Rl  is  not  in  this  database!"); 

( ! found2) 

idl_raise(IDL_ERROR, 

"The  object  for  comparison  is  not  in  this  database!"); 


;f oundl  &&  found2) 

idl_raise ( IDL_ERROR, 

"A  SERIOUS  ERROR  HAS  OCCURED 


Regroup.  Try  Again.") 
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/*  select_op  is  executed  when  Selection  is  selected  within  the  browser.  The 
sytax  for  the  operation  allows  the  user  to  input  the  single  relation  to  be 
operated  on,  attributed  name  to  select  upon,  the  comparison  operator,  and 
the  name  of  the  object  that  contains  the  attribute  value  for  comparison. 
The  comparison  object  must  be  an  instantiation  of  an  existing  relation  in 
the  database.  It  must  have  only  one  tuple  that  has  one  attribute  filled 
with  values,  the  attribute  that  you  want  to  use  for  comparison.  Then,  the 
relation  being  operated  on  is  found  and  each  tuple  has  the  specified  attr 
comparied  with  the  comparison  objects  attr  value  using  that  relations 
comparison  operator  that  was  specified  in  the  query. 

Select_op  calls  the  functions:  Select_parse_action,  report_select_error, 
and  init_temp_rel .  */ 
****************************************************************************** 

Select  Method 

****************************************************************************** 

idl_routine  void  select_op ( relation) 

relational_relation  relation; 
{ 

relational_relation  ptr_Rl , ptr_Attr , ptr_Obj , temp_relation; 
relational_database  database; 
idl_trans_mode  tmode; 
idl_univ  root; 
integer  operator; 

string  parameterl , attr, comp_obj , comp_opr;   /*  references  to  the  parameters 

Rl,  attr, comparison  object, 
and  comparison  operator 
respectively  */ 
idl_transaction  tr; 
boolean  f oundl , found2 , attr_f ound; 
boolean  is_writable  =  false, select  =  false; 
char  *attr_ptr, *delimeter  =  ",";  /*  delimeter  between  elements 

in  attribute  list  -  no  spaces  allowed  */ 

integer  i=l, count, size, index=0, ii=0; 
idl_linked_elem (relational_tuple)  comp_tuple; 

tr  =  idl_get_trans ( relation) ; 

tmode  =  idl_trans_mode_default ; 

root  =  idl_trans_get_root ( tr) ; 

database  =  idl_to (relational_database, root) ; 

foundl  =  false,- 

found2  =  false,- 

attr_found  =  false; 

is_writable  =  ( idl_trans_write_count ( tr)  >  0) ; 

brw_input ("Select  Query", 

"Please  input  the  Select  query  (Rl  select  attr  comp_op  object):  ", 
0L, 0L,0L, false, 
Select_parse_action) ; 

/*  copy  the  C  strings  Rl,  Obj  and  Attr  into  IDL  strings  */ 
parameterl  =  idl_copy_string ( tr ,  Rl )  ; 
comp_obj  =  idl_copy_string ( tr,Obj ) ; 
attr  =  idl_copy_string ( tr, Attr) ; 

if  (strcmp (Comp_opr, "=" )  ==  0) 

operator  =  1; 
else  if  (strcmp (Comp_opr, ">" )  ==  0) 

operator  =  2 ; 
else  if  (strcmp (Comp_opr, "<" )  ==  0) 

operator  =  3; 
else  if  (strcmp (Comp_opr, "/=" )  ==  0) 

operator  =  4 ; 
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else  if  (strcmp (Comp_opr, ">=" }  ==  0) 

operator  =  5; 
else  if  (strcrap (Comp_opr, "<-" )  ==  0) 

operator  =  6; 
else 

idl_raise ( IDL_ERROR, 

"It  is  hard  to  believe  that  this  error  could  occure!"); 

/*  search  the  database  for  the  two  relations:  Rl  and  Obj  */ 
idl_linked_for  ( rel at ional_relat ion, database- >rel at  ions , rel ) 
{ 

if  (strcmp  (rel->relation_name, parameterl )  ==  0) 
/*  found  relation  1  */ 
{ 

ptr_Rl  =  rel;  /*  point  at  relation  1  */ 
foundl  =  true; 
} 

if  (strcmp  ( rel->relation_name,  cornp_obj  )  ==  0) 
/*  found  the  comparison  object  */ 
{ 

ptr_Obj  =  rel; 
found2  =  true; 
} 
}  idl_end_for 

/*  check  the  attr  name  in  the  of  the  select  operation  to 
ensure  that  the  field  exists  in  the  relation  Rl  */ 

idl_array_f or ( relational_name, ptr_Rl->attribute_names,aname) 
{ 

ii++;  /*  keep  track  of  position  of  attribute  in  the  relation  schema  - 

that  is,  the  attribute  list  */ 
if  (strcmp  (aname->name, attr)  ==  0)  /*  attr  name  in  attr  list  is  a  field 

of  Rl  */ 
{ 

attr_found  =  true; 
index  =  ii; 
break; 
} 
}  idl_end_for 

if  (foundl  &&  found2  &&  attr_found) 
{ 

/*  Everything  is  ok,  perform  select  operation  on  relation  Rl . 

Iterate  through  every  tuple  of  Rl  and  compare  the  field  named  in 
the  'attr'  variable  with  the  values  of  the  object  specified  in 
comp_obj .  using  the  specified  comparison  operator  in  Comp_opr.  */ 

temp_relation  =  init_temp_rel (ptr_Rl , ptr_Obj ) ; 

idl_linked_f or ( relational_tuple, ptr_Obj -> tuples , c tuple) 
{ 

idl_linked_for ( relational_tuple,ptr_Rl->tuples, rl_tuple) 
{ 

select  =  false; 
switch  (operator) 
{ 
case  1:  /*  =  */ 

select  =  idl_vop ( rl_tuple, relational_tuple, equal_to, 

( rl_tuple, ctuple, ii) ) ; 
break; 
case  2:  /*  >  */ 

select  =  idl_vop ( rl_tuple, relational_tuple, greater_than, 

( rl_t up le, ctuple, ii ) ) ; 
break; 
case  3:  /*  <  */ 
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select  =  idl_vop (rl_tuple, relational_tuple, less_than, 

(rl_tuple, c tuple, ii ) ) ; 
break; 
default : 

idl_raise(IDL_ERROR, 

"Problems  with  operator  in  select  operation"); 
break; 
} 

if  (select) 

idl_insert_back (relational_tuple, 

t emp_re la ti on- > tuples , rl_tuple) ; 

}  idl_end_for 
}  idl_end_for 

idl_insert_back ( relational_relation, database->relations, temp_relation) 
} 
else 
{ 

report_project_error ( f oundl , f ound2 , attr_f ound) ; 
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/ 


***************************************************************************** 


*  Class  tuple  methods 
* 

*  equal_to 

*  less_than 

*  greater_than 
* 

*  initialize_tuple 

*  insert_f ields 

*  insert_tuples 
* 
*****************************************************************************/ 

******************************************************************************** 

Class  Tuple  Methods 
******************************************************************************** 

/*  this  is  the  default  duplicate  tuple  check  function  */ 

idl_routine  boolean  equal_to ( rl_tuple, r2_tuple, index) 

relational_tuple  rl_tuple, r2_tuple; 

integer  index; 
{ 

idl_transaction  tr  =  idl_get_trans ( rl_tuple)  ; 

/*  both  of  these  are  pointers,  so  if  they  point  to  the  same 
object,  then  they  are  identical  tuples.  However,  two  tuples 
that  don't  point  to  the  same  objects  may  have  the  same  values 
for  the  values  of  each  of  their  individual  objects.  */ 

if  (rl_tuple  ==  r2_tuple) 

return  true; 
else 

return  false; 
} 

/*==========================================================================*/ 

/*  this  function  is  called  by  create_tuple  of  class  relation  if  there  has  been 
no  redefinition  of  this  method  by  a  subclass  of  tuple.  If  this  function  is 
executed,  then  there  is  an  error  since  it  must  be  over-written.  */ 

idl_routine  relational_tuple  initialize_tuple (tuple_type) 

relational_tuple  tuple_type; 
{ 

relational_tuple  new_tuple; 

idl_transaction  tr  =  idl_get_trans ( tuple_type) ; 

idl_raise (IDL_ERROR, 

"There  is  no  method  for  initializing  a  tuple  of\nthe  type  that  this 
relation  contains."); 

) 

/*=================== ======== ====== ================== =======================*/ 


/*  the  default  insert  field  inserts  all  fields  of  tuple  into  result_tuple 
by  reference  */ 

idl_routine  relational_relation  insert_f ields (relation, result_rel ) 

relational_relation  relation, result_rel; 
{ 

idl_transaction  tr  =  idl_get_trans ( relation) ; 


return  result_rel  =  relation; 
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} 

/*==========================================================================*/ 

/*  the  default  insert  tuple  inserts  a  tuple  into  result_tuple  by  reference  */ 

idl_routine  relational_relation  insert_tuples (relation, result_rel ) 

relational_relation  relation, result_rel; 
{ 

idl_transaction  tr  =  idl_get_trans ( relation)  ; 

return  result_rel  =  relation; 

} 

idl_routine  boolean  less_than (rl_tuple, r2_tuple, index) 

relational_tuple  rl_tuple, r2_tuple; 

integer  index; 
{ 

idl_transaction  tr  =  idl_get_trans ( rl_tuple) ; 

idl_raise(IDL_ERROR, 

"No  less  than  method  has  been  specified  for  these  relations . \nThe  user 
must  provide  them.  No  default  can  be  provided."); 
} 


idl_routine  boolean  greater_than ( rl_tuple, r2_tuple, index) 

relational_tuple  rl_tuple, r2_tuple; 

integer  index; 
{ 

idl_transaction  tr  =  idl_get_trans ( rl_tuple) ; 

idl_raise(IDL_ERROR, 

"No  greater  than  method  has  been  specified  for  these  relations . \nThe 
user  must  provide  them.  No  default  can  be  provided."); 
} 
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* 

*  Class  name  methods 

*  name_key 

*  name_print 

idl_routine  void  name_key (name) 
relational_name  name; 

{ 

idl_univ  u; 

if  (idl_string_size (name->name)  ==  0) 
{ 

dpy_cstring ( "**  Unnamed/No  Attributes  **"); 
} 
else 
{ 

u  =  idl_to ( idl_univ, name->name) ; 
idl_vop (u, idl_univ, idl_key , (u)  )  ; 


/: 


idl_routine  void  name_print (name, mode) 
relational_name  name; 
dpy_dmode  mode; 

{ 

idl_transaction  tr  =.  idl_get_trans (name) ; 

boolean  can_write  =  idl_trans_write_count ( tr)  >  0 ; 

dpy_dmode  model; 

model  =  mode; 
model . embed  =  1 ; 

if  (can_write)  model. expand  =  1; 

if  (model . expand  >  1) 
{ 

idl_top (idl_any , idl_print, (name, mode) ) ; 
} 

dpy_attr ( relational_name, name, name, model ) ; 
dpy_eol ( ) ; 
} 
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/***************************************************************************** 

*  Class  emp_tuple  methods 

* 

*  emp_tuple_key 

*  emp_tuple_print 

*  emp_equal_to 

*  initialize_ernp_tuple 
* 
*****************************************************************************/ 

******************************************************************************** 

Class  Emp_Tuple  Methods 
******************************************************************************** 

idl_routine  void  emp_tuple_key ( tuple) 

relational_emp_tuple  tuple; 
{ 

idl_univ  u; 

if  (idl_string_size ( tuple->person->lname)  ==  0) 
{ 

dpy_cstring ( " **  Unnamed  Tuple  **"); 
} 
else 
{ 

u  =  idl_to ( idl_univ, tuple->person->lname) ; 
idl_vop (u, idl_univ, idl_key, (u) ) ; 
} 
} 

idl_routine  void  emp_tuple_print (emp_tuple, mode) 
relational_emp_tuple  emp_tuple; 
dpy_dmode  mode; 
{ 

idl_transaction  tr  =  idl_get_trans (emp_tuple) ; 
boolean  can_write  =  idl_trans_write_count (tr)  >  0; 
dpy_dmode  model ; 

model  =  mode; 
model .embed  =  1 ; 

if  (can_write)  model. expand  =  1; 

if  (model . expand  >  1) 
{ 

idl_top (idl_any , idl_print , (emp_tuple,mode) ) ; 
} 

dpy_attr ( relational_emp_tuple, emp_tuple; person, model) ; 

dpy_eol ( ) ; 

dpy_spacey (2L) ; 

dpy_eol ( ) ; 

dpy_attr (relational_emp_tuple, emp_tuple, phone, model ) ; 

dpy_eol ( ) ; 

dpy_spacey (2L) ; 

dpy_eol ( ) ; 

dpy_attr ( relational_emp_tuple, emp_tuple, address , model ) ; 

dpy_eol  ( )  ,- 

/*  add  widget  in  later  */ 

} 

/*  =  =  =  =  =  =  =  =  =:  =  =  =  =  =  =  =  =  =  ==  =  =  ===  =  =  =  =  =  =:  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  ==  =  =  =  =  =  =  =  =  =  =  =  =  =  ==  =  */ 
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/*  this  function  returns  true  if  rl  tuple  is  identical  to  r2  tuple  and 
returns  false  otherwise.  */ 

idl_routine  boolean  emp_equal_to ( rl_tuple, r2_tuple, index) 
relational_emp_tuple  rl_tuple, r2_tuple; 
integer  index; 


{ 


idl_transaction  tr  =  idl_get_trans ( rl_tuple) ; 

/*  both  of  these  are  pointers,  so  if  they  point  to  the  same 
object,  then  they  are  identical  tuples.  However,  two  tuples 
that  don't  point  to  the  same  objects  may  have  the  same  values 
for  the  values  of  each  of  their  individual  objects.  */ 

if  (index  ==  0)  /*  compare  the  entire  tuple  -  all  attributes  */ 

{ 

if  (rl_tuple  ==  r2_tuple) 

return  true; 
else  /*  not  the  same  objects  but  need  to  check  attribute  values  */ 
{ 

/*  need  to  check  each  attr  value.  The  first  time  one  is  found 
that  does  not  have  the  same  value,  the  function  stops  and 
returns  not  dulicate  (false) .  Only  if  all  attr  are  identical 
does  the  function  return  duplicate  (true).  */ 

if  (! strcmp (rl_tuple->person->f name, r2_tuple->person->fname)  && 
! strcmp (rl_tuple->person->mname, r2_tuple->person->mname)  && 
! strcmp (rl_tuple->person->lname, r2_tuple->person->lname)  && 
! strcmp (rl_tuple->person->bdate, r2_tuple->person->bdate)  && 
rl_tuple->person->ssn  ==   r2_tuple->person->ssn  && 
! strcmp ( rl_tuple->person->spouse, r2_tuple->person->spouse)  && 
! strcmp (rl_tuple->address->street , r2_tuple->address->street )  && 
! strcmp (rl_tuple->address->city , r2_tuple->address->ci ty )  && 
! strcmp (rl_tuple->address->state, r2_tuple->address->state)  && 
! strcmp (rl_tuple->address->zip, r2_tuple->address->zip)  && 
! strcmp ( rl_tuple->phone->number , r2_tuple->phone->number ) ) 
return  true; 
else 

return  false; 
} 
} 
else  /*  compare  only  the  attribute  specified  by  the  index  */ 
{ 

switch  (index) 
{ 
case  1 : 

if  (! strcmp ( rl_tuple->person->f name, r2_tuple->person->f name)  && 
! strcmp ( rl_tuple->person->mname, r2_tuple->person->mname)  && 
! strcmp ( rl_tuple- >per son- >1 name, r 2_tuple->per son- >1 name)  && 
! strcmp (rl_tuple->person->bdate, r2_tuple->person->bdate)  && 
rl_tuple->person->ssn  ==  r2_tuple->person->ssn  && 
! strcmp ( rl_tuple->person->spouse, r2_tuple->person->spouse) ) 
return  true; 
else 

return  false; 
break; 
case  2 : 

if  ( ! strcmp (rl_tuple->address->street , r2_tuple->address->street )  && 
! strcmp (rl_tuple->address->city , r2_tuple->address->city )  && 
! strcmp (rl_tuple->address->state, r2_tuple->address->state)  && 
! strcmp (rl_tuple->address->zip, r2_tuple->address->zip) ) 
return  true; 
else 

return  false; 
break; 
case  3 : 

if  ( ! strcmp ( rl_tuple->phone->number , r2_tuple->phone->number ) ) 
return  true; 
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else 

return  false; 
break; 
case  4 : 

idl_raise ( IDL_ERROR, 

"Widget  is  not  defined  and  thus  can't  be  compared!"); 
break; 
default: 

idl_raise(IDL_ERROR, 

"An  ugly  error  has  occured  in  emp_equal_to" ) ; 
break; 


/*  this  function  returns  true  if  rl  tuple  is  less  than  r2  tuple  and 
returns  false  otherwise.  */ 

idl_routine  boolean  emp_less_than (rl_tuple, r2_tuple, index) 
relational_emp_tuple  rl_tuple, r2_tuple; 
integer  index; 

{ 

idl_transaction  tr  =  idl_get_trans ( rl_tuple) ; 

switch  (index) 
{ 
case  1 : 

if  ( (strcmp (rl_tuple->person->f name, r2_tuple->person->f name)  <  0)  && 
(strcmp (rl_tuple->person->mname, r2_tuple->person->mname)  <  0)  && 
(strcmp (rl_tuple->person->lname, r2_tuple->person->lname)  <  0)  && 
(strcmp (rl_tuple->person->bdate, r2_tuple->person->bdate)  <  0)  && 
rl_tuple->person->ssn  <  r2_tuple->person->ssn  && 
(strcmp (rl_tuple->person->spouse, r2_tuple->person->spouse)  <  0) ) 
return  true; 
else 

return  false; 
break; 
case  2 : 

if  ( (strcmp (rl_tuple->address->street , r2_tuple->address->street)  <  0)  && 
(strcmp (rl_tuple->address->city , r2_tuple->address->city)  <  0)  && 
(strcmp (rl_tuple->address->state, r2_tuple->address->state)  <  0)  && 
(strcmp (rl_tuple->address->zip/ r2_tuple->address->zip)  <  0)) 
return  true; 
else 

return  false; 
break; 
case  3 : 

if  ( (strcmp (rl_tuple->phone->number , r2_tuple->phone->number )  <  0)) 

return  true; 
else 

return  false; 
break; 
case  4: 

idl_raise(IDL_ERROR, 

"Widget  is  not  defined  and  thus  can't  be  compared!"); 
break; 
default: 

idl_raise (IDL_ERROR, 

"An  ugly  error  has  occured  in  emp_less_than" ) ; 
break; 
} 
} 

/*    this  function  returns  true  if  rl  tuple  is  greater  than  r2  tuple  and 
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returns  false  otherwise.  */ 

idl_routine  boolean  emp_greater_than (rl_tuple, r2_tuple, index) 
relational_emp_tuple  rl_tuple, r2_tuple; 
integer  index; 

{ 

idl_transaction  tr  =  idl_get_trans ( rl_tuple) ; 

switch  (index) 
{ 
case  1 : 

if  ( (strcmp (rl_tuple->person->f name, r2_tuple->person->f name)  >  0)  && 
(strcmp (rl_tuple->person->mname, r2_tuple->person->mname)  >  0)  && 
(strcmp (rl_tuple->person->lname, r2_tuple->person->lname)  >  0)  && 
(strcmp (rl_tuple->person->bdate, r2_tuple->person->bdate)  >  0)  && 
rl_tuple->person->ssn  >  r2_tuple->person->ssn  && 
(strcmp (rl_tuple->person->spouse, r2_tuple->person->spouse)  >  0) ) 
return  true; 
else 

return  false; 
break; 
case  2  : 

if  ( (strcmp (rl_tuple->address->street , r2_tuple->address->street)  >  0)  && 
(strcmp (rl_tuple->address->city , r2_tuple->address->city)  >  0)  && 
(strcmp (rl_tuple->address->state, r2_tuple->address->state)  >  0)  && 
(strcmp (rl_tuple->address->zip, r2_tuple->address->zip)  >  0)) 
return  true; 
else 

return  false; 
break; 
case  3  : 

if  ( (strcmp (rl_tuple->phone->number, r2_tuple->phone->number)  >  0)) 

return  true; 
else 

return  false; 
break; 
case  4 : 

idl_raise(IDL_ERROR, 

"Widget  is  not  defined  and  thus  can't  be  compared!"); 
break; 
default : 

idl_raise(IDL_ERROR, 


break; 
} 


"An  ugly  error  has  occured  in  emp_greater_than" ) ; 
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/*  this  function  is  called  from  create_tuple.  It  redefines  the  implementation 
for  the  class  tuples  method  initialize_tuples .  Specifically,  a  new  employee 
tuple  is  created  and  given  initial  values  (all  of  which  are  legal) . 
It  returns  a  tuple  to  create_tuple  which  then  allows  the  user  to  initialize 
this  tuple  with  values.  Each  subtype  of  tuple  needs  to  have  a  function 
like  this.  */ 

idl_routine  relational_tuple  initialize_emp_tuple ( tuple_type) 
relational_tuple  tuple_type; 


{ 


relational_emp_tuple  new_tuple; 
idl_transaction  tr  =  idl_get_trans ( tuple_type) ; 
string  empty  =  idl_copy_string ( tr, "" ) ; 

new_tuple  -   idl_new ( tr, relational_emp_tuple) ;  /*  must  still  assign 

legal  values*/ 

new_tuple->person  =  idl_new (tr, relational_person) ; 
new_tuple->person->fname  =  empty; 
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new_tuple->person->mname  =  empty; 
new_tuple->person->lname  =  empty; 
new_tuple->person->bdate  =  empty; 
new_tuple->person->ssn  =  0; 
new_tuple->person->spouse  =  empty; 

new_tuple->address  =  idl_new( tr, relational_addr ) ; 
new_tuple->address->street  =  empty; 
new_tuple->address->city  =  empty; 
new_tuple->address->state  =  empty; 
new_tuple->address->zip  =  empty; 

new_tuple->phone  =  idl_new ( tr , relational_phone_number) 
new_tuple->phone->number  =  empty; 

return  idl_to ( relational_tuple, new_tuple) ; 

} 
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* 

*  Class  person  methods 

* 

*  person_key 

*  person_print 

idl_routine  void  person_k:ey  (person) 
relational_person  person; 

{ 

boolean  bl,b2,b3; 
bl  =  rexists (person, f name) 
b2  =  rexists (person, mname) 
b3  =  rexists (person, lname) 
if  (bl) 
{ 

dpy_cstring (person->f name) ; 
if  (b2  I  I  b3) 
{ 

dpy_spacex ( 1L ) ; 
} 
} 
if  (b2) 
{ 

dpy_cstring (person->mname) ; 
if  (b3) 
{ 

dpy_spacex ( 1L) ; 
} 
} 
if  (b3) 
{ 

dpy_cstring ( person- >1 name) ; 
} 
if  (!  bl  &&  !  b2  &&  !  b3) 
{ 

dpy_cstring ("**  No  name  **"); 


/' 


idl_routine  void  person_print (person, mode) 
relational_person  person; 
dpy_dmode  mode; 
{ 

boolean  bl , b2 , b3 ; 

if  (mode. expand  >  1) 
{ 

idl_top (idl_any , idl_print , (person, mode) ) ; 
return; 
} 
bl  =  dexists (person, fname) 
b2  =  dexists (person, mname) 
b3  =  dexists (person, lname) 
if  (mode. expand  >  0)  dpy_spacey (1L) ; 
if  (bl) 
{ 

dpy_attr ( relational_person, person, fname, mode) ; 
if  (b2  I  I  b3) 
( 

dpy_spacex( 1L)  ; 
) 
} 
if  (b2) 
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} 


{ 

dpy_attr ( relational_per son, person, mname, mode) ; 
if  (b3) 
{ 

dpy_spacex(lL) ; 


if  (b3) 
{ 

dpy_attr ( relational_person, person, lname,mode) ; 
} 
if    ( !    bl    &&    !    b2    ScSc    !    b3) 
{ 

dpy_cstring ("**  No  name  **"); 
} 
if  (dexists (person, bdate) ) 
{ 

dpy_spacex( 1L) ; 
dpy_cstring (" ( " )  ; 

dpy_attr ( re la tional_per son, person, bdate, mode) ; 
dpy_cstring (")"); 
} 
else 
{ 

dpy_cstring ("   **  No  Birth  Date  Entered  **"); 
} 
if  (dexists (person, spouse)  II  pdexists (person, sptr) ) 
{ 

if  (mode. expand  >  0  II  !  pdexists (person, sptr ) ) 
{ 

dpy_cstring ( "  [") ; 

dpy_attr ( relational_person, person, spouse, mode) ; 
dpy_c  s  t  r i  ng ( " ] " )  ; 
} 
if  (pdexists (person, sptr) ) 
{ 

if  (idl_get_display_embed(relational_person, sptr) ) 
{ 

dpy_eol ( ) ; 

dpy_attr ( relational_person, person, sptr, mode) ; 
} 
else 
{ 

dpy_cstring ( "  [ " ) ; 

dpy_attr ( relational_person, person, sptr, mode) ; 
dpy_cstring ("]"); 
} 


dpy_eol ( ) ; 

dpy_spacey (1L) ; 

dpy_cstring("SSN:  " )  ; 

dpy_attr ( relational_person, person, ssn,mode) ; 

dpy_eol ( ) ; 
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*  Class  addr  methods 

* 

*  addr_key 

*  addr_print 
* 

idl_routine  void  addr_key (address) 

relational_addr  address; 
{ 

if  (idl_string_size (address->state)  ==  0) 
{ 

dpy_cstring ("**  No  Street  Address  **"); 
dpy_eol ( ) ; 
} 
else 
{ 

dpy_cstring (address->street )  ; 
dpy_eol ( ) ; 
} 
} 


/■ 


idl_routine  void  addr_print (address, mode) 
relational_addr  address; 
dpy_dmode  mode; 
{ 

idl_transaction  tr  =  idl_get_trans (address)  ; 
boolean  can_write  =  idl_trans_write_count ( tr)  >  0, 

if  (can_write)  mode. expand  =  1; 

dpy_attr (relational_addr, address, street , mode) ; 

dpy_eol ( ) ; 

dpy_spacey ( 1L ) ; 

dpy_attr ( relational_addr, address, city , mode) ; 

if  ( (mode .expand  >  0  I  I 

(idl_get_di splay ( relational_addr, state)  && 
(address->state  ! =  0  && 
(idl_string_size (address->state) )  !=  0)))) 
dpy_cstring (","); 

dpy_spacex ( 1L)  ; 

dpy_attr ( relational_addr, address, state, mode) ; 

dpy_eol ( ) ; 

dpy_spacey ( 1L)  ; 

dpy_spacex( 15L)  ; 

dpy_attr ( relational_addr, address, zip, mode) ; 

dpy_eol ( ) ; 
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* 

*  Class  phone_number  methods 
* 

*  phone_number_print 
* 
it**********************************!?*****************************************/ 

idl_routine  void  phone_number_print (pnumber ,mode) 
relational_phone_number  pnumber; 
dpy_dmode  mode; 
{ 

dpy_attr ( relational_phone_number, pnumber, number , mode) ; 
dpy_eol { ) ; 
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/••••♦♦•••♦a****************************************************************** 

* 

*  Class  proj_tuple  methods 

* 

*  proj_tuple_key 

*  proj_tuple_print 

*  initialize_proj_tuple 

*  proj_equal_to 

*  proj_less_than 

*  proj_greater_than 
* 

*****************************************************************************  / 
******************************************************************************** 

Class  Proj_tuple  Methods 
**************************************************** 

idl_routine  void  proj_tuple_key (pro j_tuple) 

relational_pro j_tuple  proj_tuple; 
{ 

dpy_integer (proj_tuple->essn,  9)  ; 

dpy_spacex(4L)  ; 

dpy_integer  (proj_tuple->proj_nurn,  3  )  ; 

dpy_spacex(4L) ; 

dpy_rational (proj_tuple->hours,  6)  ; 

dpy_eol ( ) ; 
} 


idl_routine  void  proj_tuple_print (proj_tuple,mode) 
relational_pro j_tuple  proj_tuple; 
dpy_dmode  mode ; 
{ 

idl_transaction  tr  =  idl_get_trans (proj_tuple) ; 
boolean  can_write  =  idl_trans_write_count (tr)  >  0; 

if  (can_write)  mode. expand  =  1; 

dpy_attr ( relational_proj_tuple, proj_tuple, essn,mode) ; 
dpy_eol ( ) ; 
dpy_spacey (1L) ; 

dpy_attr (relational_proj_tuple, proj_tuple, pro j_num, mode) ; 
dpy_eol ( ) ; 
dpy_spacey ( 1L) ; 

dpy_attr ( relational_pro j_tuple, proj_tuple, hours,  mode) ; 
dpy_eol ( ) ; 
} 

/*  =  =  =======  =  ===  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  ;:  =  =  =  =  =  =  ::  =  =  =  =  =  =  =  =  =  =  ^  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  ===  =  =  =  =  =  */ 

/*  this  function  is  called  from  create_tuple.  It  redefines  the  implementation 
for  the  class  tuples  method  initialize_tuples .  Specifically,  a  new  project 
tuple  is  created  and  given  initial  values  (all  of  which  are  legal) . 
It  returns  a  tuple  to  create_tuple  which  then  allows  the  user  to  initialize 
this  tuple  with  values.  Each  subtype  of  tuple  needs  to  have  a  function 
like  this.  */ 

idl_routine  relational_tuple  initialize_proj_tuple ( tuple_type) 

relational_tuple  tuple_type; 
{ 

relational_proj_tuple  new_tuple; 

idl_transaction  tr  =  idl_get_trans ( tuple_type) ; 

string  empty  =  idl_copy_string ( tr, " " )  ; 

new_tuple  =  idl_new (tr, relational_proj_tuple) ; 
/*  must  still  assign  legal  values*/ 
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new_tuple->essn  =  0; 
new_tuple->proj_num  =  0 ; 
new_tuple->hours  =  0.0; 

return  idl_to (relational_tuple, new_tuple) ; 


/*  this  function  returns  true  if  rl  tuple  is  equal  to  r2  tuple  and 
returns  false  otherwise.  */ 

idl_routine  boolean  proj_equal_to (rl_tuple, r2_tuple, index) 
relational_proj_tuple  rl_tuple, r2_tuple; 
integer  index; 


{ 


idl_transaction  tr  =  idl_get_trans ( rl_tuple) ; 

switch  (index) 
{ 
case  1 : 

if  ( rl_tuple->essn  ==  r2_tuple->essn) 

return  true; 
else 

return  false; 
break; 
case  2 : 

if  (rl_tuple->proj_num  ==  r2_tuple->proj_num) 

return  true; 
else 

return  false; 
break; 
case  3 : 

if  (rl_tuple->hours  ==  r2_tuple->hours) 

return  true; 
else 

return  false; 
break; 
default : 

idl_raise(IDL_ERROR, 

"An  ugly  error  has  occured  in  proj_equal_to" ) ; 
break; 
} 
} 

/*  this  function  returns  true  if  rl  tuple  is  less  than  r2  tuple  and 
returns  false  otherwise.  */ 

idl_routine  boolean  proj_less_than ( rl_tuple, r2_tuple, index) 

relational_proj_tuple  rl_tuple, r2_tuple; 

integer  index; 
{ 

idl_transaction  tr  =  idl_get_trans (rl_tuple) ; 

switch  (index) 
{ 
case  1 : 

if  (rl_tuple->essn  <  r2_tuple->essn) 

return  true; 
else 

return  false; 
break; 
case  2 : 

if  (rl_tuple->proj_num  <  r2_tuple->proj_num) 
return  true; 
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else 

return  false; 
break; 
case  3 : 

if  (rl_tuple->hours  <  r2_tuple->hours) 

return  true; 
else 

return  false; 
break; 
default : 

idl_raise(IDL_ERROR, 

"An  ugly  error  has  occured  in  proj_less_than" 
break; 
} 


/*  this  function  returns  true  if  rl  tuple  is  greater  than  r2  tuple  and 
returns  false  otherwise.  */ 

idl_routine  boolean  proj_greater_than ( rl_tuple, r2_tuple, index) 

relational_proj_tuple  rl_tuple, r2_tuple; 

integer  index; 
{ 

idl_transaction  tr  =  idl_get_trans ( rl_tuple) ; 

switch  (index) 
{ 
case  1 : 

if  (rl_tuple->essn  >  r2_tuple->essn) 

return  true; 
else 

return  false; 
break; 
case  2 : 

if  (rl_tuple->proj_num  >  r2_tuple->proj_num) 

return  true; 
else 

return  false; 
break; 
case  3 : 

if  (rl_tuple->hours  >  r2_tuple->hours) 

return  true; 
else 

return  false; 
break; 
default : 

idl_raise ( IDL_ERROR, 

"An  ugly  error  has  occured  in  proj_greater_than" ) ; 
break; 
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/***************************************************************************** 
* 

*  Class  cartl_result_tuple  methods 
* 

*  cartl_result_tuple_key 

*  cartl_result_tuple_print 

*  initialize_cartl_resul_tuple 

*  insert_cartl_result_tuples 
* 
*****************************************************************************/ 

******************************************************************************** 

Class  Cartl_Result_Tuple  Methods 
******************************************************************************** 

idl_routine  void  cartl_result_tuple_key (cartl_tuple) 

relational_cartl_result_tuple  cartl_tuple; 
{ 

idl_univ  u; 

u  =  idl_to ( idl_univ, cartl_tuple->person->lname) ; 
idl_vop (u, idl_univ, idl_key , (u) ) ; 
dpy_spacex( 4L) ; 

dpy_integer (cartl_tuple->essn, 9 ) ; 
dpy_spacex(4L) ; 

dpy_integer (cartl_tuple->proj_nurn, 3 ) ; 
dpy_spacex(4L) ; 

dpy_rational (cart l_tuple->hours , 6 ) ; 
dpy_eol ( ) ; 
} 


idl_routine  void  cartl_result_tuple_print (cartl_tuple,mode) 
relational_cartl_result_tuple  cartl_tuple; 
dpy_dmode  mode; 
{ 

idl_transaction  tr  =  idl_get_trans (cartl_tuple) ; 
boolean  can_write  =  idl_trans_wri te_count ( tr)  >  0; 

if  (can_write)  mode. expand  =  1; 

mode . embed  =  1 ; 

if  (mode. expand  >  1) 
{ 

idl_top (idl_any , idl_print , (cartl_tuple,mode) ) ; 
} 

dpy_attr ( relational_emp_tuple, car tl_tuple, per son, mode) ; 

dpy_eol ( ) ; 

dpy_spacey (1L) ; 

dpy_eol ( ) ; 

dpy_a  ttr(relati  ona l_emp_t up 1 e , c  a  r  1 1 _t up 1 e , phone , mode ) ; 

dpy_eol ( ) ; 

dPy_spacey (1L) ; 

dpy_eol  ( ) ; 

dpy_attr ( relational_emp_tuple, cartl_tuple, address, mode) ; 

dpy_eol ( ) ; 

dpy_spacey ( 1L ) ; 

/*  add  widget  in  later  when  it  is  defined  as  something  */ 

dpy_attr ( relational_cartl_result_tuple, cartl_tuple, essn,mode) ; 

dpy_eol ( ) ; 

dpy_spacey ( 1L) ; 

dpy_attr (relational_cartl_result_tuple, cartl_tuple, pro j_num, mode) ; 
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dpy_eol ( ) ; 
dpy_spacey  ( 1L)  ; 

dpy_attr ( relational_cartl_result_tuple, cartl_tuple, hours, mode) ; 
dpy_eol ( ) ; 
} 

/*  this  function  is  called  from  create_tuple .  It  redefines  the  implementation 
for  the  class  tuples  method  initialize_tuples .  Specifically,  a  new  project 
tuple  is  created  and  given  initial  values  (all  of  which  are  legal) . 
It  returns  a  tuple  to  create_tuple  which  then  allows  the  user  to  initialize 
this  tuple  with  values.  Each  subtype  of  tuple  needs  to  have  a  function 
like  this.  */ 

idl_routine  relational_tuple  initialize_cartl_resul_tuple (tuple_type) 

relational_tuple  tuple_type; 
{ 

relational_cartl_result_tuple  new_tuple; 

idl_transaction  tr  =  idl_get_trans ( tuple_type) ; 

string  empty  =  idl_copy_string ( tr , " " ) ; 

new_tuple  =  idl_new ( tr, relational_cartl_result_tuple) ; 
/*  must  still  assign  legal  values*/ 

new_tuple->person  =  idl_new ( tr, relational_person)  ; 
new_tuple->person->f name  =  empty; 
new_tuple->person->mname  =  empty; 
new_tuple->person->lname  =  empty; 
new_tuple->person->bdate  =  empty; 
new_tuple->person->ssn  =  0; 
new_tuple->person->spouse  =  empty; 

new_tuple->address  =  idl_new( tr, relational_addr) ; 
new_tuple->address->street  =  empty; 
new_tuple->address->city  =  empty; 
new_tuple->address->state  =  empty; 
new_tuple->address->zip  =  empty; 

new_tuple->phone  =  idl_new ( tr , relational_phone_number) ; 
new_tuple->phone->number  =  empty; 

/*  new_tuple->widget  needs  to  have  widget  defined  first  */ 

new_tuple->essn  =  0 ; 
new_tuple->proj_num  =  0; 
new_tuple->hours  -    0.0; 

return  idl_to (relational_tuple, new_tuple) ; 


static  relational_relation  insert_cartl_result_tuples (rl, r2 , r3 ) 

relational_relation  rl,r2,r3; 
{ 

relational_cartl_result_tuple  new_tuple; 

relational_emp_tuple  rell; 

relational_proj_tuple  rel2; 

idl_transaction  tr  =  idl_get_trans ( rl ) ; 

/*  get  rid  of  any  tuples  that  may  be  in  the  resultant  relation  structure 
prior  to  insert  the  new  result  */ 

r3->tuples  =  idl_empty_l inked ( tr, relational_tuple) ; 

idl_linked_for  (relational_tuple, rl->tuples, rl_tuple) 
( 
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idl_linked_for  (relational_tuple, r2-> tuples, r2_tuple) 

{ 

/*  send  message  Co  get  a  new  tuple  created  with  valid  default 
values.  */ 

new_tuple  =  idl_to ( relational_cartl_resul t_tuple, 

idl_vop ( r3->tuple_type, relational_tuple,  initialize_tuple, 
(r3->tuple_type) ) ) ; 

rell  =  idl_to (relational_emp_tuple, rl_tuple) ; 
rel2  =  idl_to (relational_proj_tuple, r2_tuple) ; 

new_tuple->person->fname  =  rell->person->f name 

new_tuple->person->mname  =  rell->person->mname 

new_tuple->person->lname  =  rell->person->lname 

new_tuple->person->bdate  =  rell->person->bdate 

new_tuple->person->ssn  =  rell->person->ssn; 

new_tuple->address->street  =  rell->address->street ; 
new_tuple->address->city  =  rell->address->city ; 
new_tuple->address->state  =  rell->address->state; 
new_tuple->address->zip  =  rell->address->zip; 

new_tuple->phone->number  =  rell->phone->number; 

/*  new_tuple->widget  needs  to  have  widget  defined  first  */ 

new_tuple->essn  =  rel2->essn; 
new_tuple->proj_num  =  rel2->proj_num; 
new_tuple->hours  =  rel2 ->hours; 

idl_insert_back (relational_tuple, r3->tuples,new_tuple) ; 

}  idl_end_for 
}  idl_end_for 

return  r3 ; 

} 
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* 

*  Class  projectl_result_tuple  methods 
* 

*  projectl_result_tuple_key 

*  projectl_result_tuple_print 

*  initialize_projectl_resul_tuple 

*  insert_projectl_result_f Ids 
* 

it******************************************************************************* 

Class  Projectl_Result_Tuple  Methods 
**************************************************** 

idl_routine  void  projectl_resul t_tuple_key (projectl_result_tuple) 

relational_projectl_result_tuple  pro jectl_result_tuple ; 
{ 

dpy_rational (projectl_result_tuple->hours , 6 )  ; 

dpy_spacex(4L) ; 

dpy_integer (projectl_result_tuple->essn, 9 ) ; 

dpy_eol ( ) ; 
} 


idl_routine  void  projectl_result_tuple_print (projectl_resul t_tuple,mode) 
relational_projectl_result_tuple  projectl_result_tuple; 
dpy_drnode  mode; 
{ 

idl_transaction  tr  =  idl_get_trans (projectl_resul t_tuple) ; 
boolean  can_write  =  idl_trans_write_count (tr)  >  0 ; 

if  (can_write)  mode. expand  =  1; 

dpy_attr ( relational_pro jectl_result_tuple, project l_result_tuple, hours, mode) ; 
dpy_eol ( ) ; 
dpy_spacey ( 1L) ; 

dpy_attr ( relationai_projectl_result_tuple,projectl_result_tuple,essn,mode) ; 
dpy_eol ( ) ; 
} 

idl_routine  relational_tuple  initialize_pro jectl_resul_tuple ( tuple_type) 

relational_tuple  tuple_type; 
{ 

relational_projectl_result_tuple  new_tuple; 

idl_transaction  tr  =  idl_get_trans ( tuple_type) ; 

new_tuple  =  idl_new ( tr, relational_pro ject l_result_tuple) ; 
/*  must  still  assign  legal  values*/ 


} 


/■ 


new_tuple->essn  =  0 ; 
new_tuple->hours  =  0.0; 

return  idl_to (relational_tuple, new_tuple) ; 


idl_routine  relational_relation  insert_projectl_result_f Ids (rel , result_rel) 

relational_relation  rel, result_rel ; 
{ 

relational_projectl_result_tuple  new_tuple; 

relational_proj_tuple  rell; 
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idl_transaction  tr  =  idl_get_trans ( rel ) ; 

resul t_rel->tuples  =  idl_empty_linked (tr, relational_tuple) ; 

new_tuple  =  idl_new(tr, relational_projectl_result_tuple) ; 
/*  must  still  assign  legal  values*/ 

idl_linked_for  (relational_tuple, rel->tuples, rl_tuple) 
C 

/*  send  message  to  get  a  new  tuple  created  with  valid  default 
values.  */ 

new_tuple  =  idl_to ( relational_pro jectl_result_tuple, 
idl_vop (result_rel- 
>tuple_type, relational_tuple, initialize_tuple, ( resul t_rel->tuple_type) 

rell  =  idl_to (relational_proj_tuple, rl_tuple) ; 

new_tuple->essn  =  rell->essn; 
new_tuple->hours  =  rell->hours; 

idl_insert_back (relational_tuple, resu 1 t_r el -> tuples, new_tuple) ; 

}  idl_end_for 

return  result_rel; 

} 
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/it*************************************************************************** 
* 

*  General  functions  to  display  a  character  string  and  an  integer 

* 

*  exit_action 

*  char_screen 

*  integer_screen 
* 

/*  called  by  char_screen  and  integer_screen  to  exit  the  pop  up  window  */ 

idl_routine  void  exit_action (i) 

integer  i ; 
{ 

dpy_qu  i  t ( )  ; 
} 


/*  display  the  string  s  on  a  pop-up  screen  using  dpy_active (char_screen, s ; 
Note:  the  browser  restricts  s  to  80  characters  */ 


idl_routine  void  char_screen(s, x,y ) 
string  s; 
integer  x,y; 


{ 


dpy_open ( "Display  String" , true) ; 

dpy_open ( "format" , true) ; 

brw_cmd( "Exit" , "exit  this  screen" , exit_action, 0, BRW_SCREEN) ; 

dpy_eol ( ) ; 

dpy_spacey (2 )  ; 

dpy_eol ( ) ; 

dpy_c  s  t  r  i  ng ( s )  ; 

dpy_spacey (2 ) ; 

dpy_eol ( )  ; 

dpy_close ( )  ; 

brw_input_area (y-3 , true) ; 

dpy_close ( ) ; 

dpy_boxed(x,y) ; 


/*  display  the  integer  s  on  a  pop-up  screen  */ 
idl_routine  void  integer_screen (s , x,y ) 

integer  s; 

integer  x,y; 


{ 


dpy_open ( "Display  Integer" , true) ; 

dpy_open ( "format" , true) ; 

brw_cmd("Exit" , "exit  this  screen" , exit_act ion, 0, BRW_SCREEN) ; 

dpy_eol ( ) ; 

dpy_spacey (1 ) ; 

dpy_eol ( ) ; 

dpy_integer ( s ,  5  )  ; 

dpy_spacey  (2 )  ; 

dpy_eo 1 ( } ; 

dpy_close( )  ; 

brw_input_area (y-3 , true) ; 

dpy_close ( )  ; 

dpy_boxed(x,y) ; 
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/*************************************' 
* 

*    Binding  and  Initialization 


********************************** 


**********************: 


*****************- 


****************************** 


idl_def ine_ops  relational_opbind ( ) 

{ 

idl  bind_root (relational) ; 


idl_bind 

idl_bind 
idl_bind 

idl_bind 
idl_bind 
idl_bind 
idl_bind 

idl_bind 
idl_bind 
idl_bind 
idl_bind 
idl_bind 

idl_bind 
idl_bind 
idl_bind 

idl_bind 
idl_bind 
idl_bind 

idl_bind 
idl_bind 

idl_bind 
idl_bind 
idl_bind 
idl_bind 
idl_bind 
idl_bind 

idl_bind 
idl_bind 

idl_bind 
idl_bind 

idl_bind 

idl_bind 
idl_bind 
idl_bind 
idl_bind 
idl_bind 
idl  bind 


idl_bind 
idl_bind 
idl_bind 
idl  bind 


idl_bind 

idl  bind 


"databasG_key " , database_key ) ; 
"database_print" , database_print ) ; 
"create_relation" , create_relation) ; 

"relation_key" , relation_key ) ; 
"relation_print" , relation_print) ; 
"create_tuple" , create_tuple) ; 
"ck_union_compatability" , ck_union_compatability ) 

"union_op" ,union_op) ; 
"cart_prod_op" , cart_prod_op) ; 
"set_dif f_op" , set_dif f_op) ; 
"project_op" ,project_op) ; 
"select_op" , select_op) ; 

"equal_to" , equal_to) ; 
"less_than" , less_than) ; 
"greater_than" , greater_than) ; 

"initialize_tuple" , initialize_tuple) ; 
"insert_f ields" , insert_f ields) ; 
"insert_tuples" , insert_tuples ) ; 

"name_key" , name_key ) ; 
"name_print" , name_print) ; 

"emp_tuple_key" , emp_tuple_key ) ; 
"emp_tuple_print "  ,  ernp_tuple_print )  ; 
"emp_equal_to" , emp_equal_to) ; 
"emp_less_than" , emp_less_than) ; 
"emp_grGater_than" , emp_greater_than) ; 
"initialize_emp_tuple" , ini tialize_emp_tuple) ; 

"person_key" ,person_key ) ; 
"person_print" ,person_print) ; 

"addr_key" , addr_key) ; 
"addr_print" , addr_print) ; 

"phone_nuinber_print"  ,phone_number_print)  ; 

"pro j_tuple_key" , pro j_tuple_key ) ; 

"P^oJ_tuple_print" ,pro j_tuple_print ) ; 

"proj_equal_to" , proj_equal_to) ; 

"pro j_less_than" , pro j_less_than) ; 

"pro j_greater_than" , proj_greater_than) ; 

"initialize_proj_tuple" , initialize_proj_tuple) ; 


"cartl_result_tuple_key" , cartl_result_tuple_key ) ; 
"cartl_result_tuple_print" , cartl_result_tuple_print ) ; 
"initialize_cartl_resul_tuple" , initialize_cartl_resul_tuple) 
"insert_cartl_result_tuples" , insert_cartl_result_tuples) ; 


"projectl_result_tuple_key" , projectl_result_tuple_key) ; 
"projectl_result_tuple_print" , projectl_result_tuple_print; 
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idl_bind("initialize_projectl_resul_tuple", initialize_projectl_resul_tuple) 
idl_bind("insert_projectl_result_flds", insert_projectl_result_f Ids) ; 
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APPENDIX  D:  A  SAMPLE  R/OODBMS  DATABASE  ASCII  CLUSTER  FILE 


--  Generated  by  IDB  System  Version  1.1 

@[  cid  <  16#e6842701  16#00000000  16#00000036 

lid_seed  3  5  66  ]@ 
x355" 


xl 
x2 
x3 
x4 
x5 
x6 
x7 
x8 
x9 


1063@  name t  name  1064@  "person"  ] 

10650  name [  name  1066©  "address"  ] 

1067©  name[  name  1068©  "phone"  ] 

1069©  name[  name  1070©  "widget"  ] 

1257©  name [  name  1267©  "person"  ] 

1259©  name[  name  1266©  "addr"  ] 

1261©  name [  name  1268©  "phone_number"  ] 

1272©  name[  name  1275©  "idl_univ"  ] 

1072©  person!  fname  X176"  ;  mname  xl77"  ;  lname  xl78"  ;  bdate  xl79"  ;  ssn 


122121212  ;  spouse  3015©  "Lisa"  ;  sptr  nil 


xlO 
xll 
xl2 
xl3 


1074©  addr[  street  xl81"  ;  city  xl82~  ;  state  xl83"  ;  zip  xl84's  ] 

107  5©  phone_number [  number  X18  6"  ] 

1076©  emp_tuple[  person  x9"  ;  address  xlO"  ;  phone  xll"  ;  widget  nil  ] 

1078©  person  [  fname  X201"  ;  mname  x202~  ;  lname  x203"  ;  bdate  x204/v  ;  ssn 


110121212  ;  spouse  3024©  "Stephanie"  ;  sptr  nil 


1080©  addr[  street  x206"  ;  city  x207/N  ;  state  x208~  ;  zip  x209"  ] 

1081©  phone_number  [  number  x211/v  ] 

1082©  emp_tuple[  person  xl3"  ;  address  xl4"  ;  phone  xl5~  ;  widget  nil  ] 

1084©  person!  fname  x226"  ;  mname  x227"  ;  lname  x228/s  ;  bdate  x229~  ;  ssn 


xl4 

xl5 

xl6 

xl7 

220121212  ;  spouse  3033©  "Joan"  ;  sptr  nil  ] 

xl8 

xl9 

x20 

X21 


1086©  addr[  street  x231"  ;  city  x232"  ;  state  x233"  ;  zip  x234"  ] 

1087©  phone_number [  number  x23  6~  ] 

1088©  emp_tuple[  person  xl7/N  ;  address  xl8~  ;  phone  xl9"  ;  widget  nil  ] 

1090©  person!  fname  x251'N  ;  mname  x252~  ;  lname  x253"  ;  bdate  x254"  ;  ssn 


120926190  ;  spouse  3040©  "Karin"  ;  sptr  nil 


x22 
x23 
x2  4 
x25 


1094©  addr[  street  x256~  ;  city  x257"  ;  state  x258"  ;  zip  x259"  ] 

1095©  phone_number [  number  x261~  ] 

1096©  emp_tuple[  person  x21"  ;  address  x22"  ;  phone  x23~  ;  widget  nil  ] 

1098©  person [  fname  x276~  ;  mname  x277~  ;  lname  x278"  ;  bdate  x279~  ;  ssn 


123456789  ;  spouse  1097©  ""  ;  sptr  nil  ] 


x26 
x27 
x28 
x29 


1102©  addr[  street  x281"  ;  city  x282"  ;  state  x283"  ;  zip  x284"  ] 

1105©  phone_number [  number  x286~  ] 

1106©  emp_tuple[  person  x25~  ;  address  x26"  ;  phone  x27"  ;  widget  nil  ] 

1348©  person [  fname  x301"  ;  mname  x302"  ;  lname  x303"  ;  bdate  x304"  ;  ssn 


991221234  ;  spouse  3053©  "Lesa"  ;  sptr  nil  ] 

x30:  1349©  addr [  street  x306"  ;  city  X307"  ;  state  x308"  ;  zip  x309"  ] 

x31:  1350©  phone_number [  number  x311"  ] 

x32:  1347©  emp_tuple[  person  x29"  ;  address  x30"  ;  phone  x31"  ;  widget  nil  ] 

x33:  1354©  person [  fname  1355©  ""  ;  mname  1356©  ""  ;  lname  1382©  ""  ;  bdate  1358© 

""  ;  ssn  0  ;  spouse  1359©  ""  ;  sptr  nil  ] 

x34:  1360©  addr [  street  1361©  ""  ;  city  1362©-  ""  ;  state  1363©  ""  ;  zip  1364©  ""  ] 

x3  5:  13  65©  phone_number [  number  13  6  6©  ""  ] 

x36:  1353©  emp_tuple[  person  x33~  ;  address  x34"  ;  phone  x35~  ;  widget  nil  ] 

x37 :  1107©  relation!  relation_name  1108©  "rl"  ;  attribute_names  x38"  ; 

attribute_types  x39"  ;  tuples  1110©  <  xl2/N  xl6"  x20"  x24"  x28"  x32"  >  ;  tuple_type 

x3  6"  ;  key  x3  53"  ] 

x38:  1113©  <  xl"  x2"  x3"  x4"  > 

x39:  1254©  <  x5"  x6"  x7"  x8"  > 

x40:  1239©  person [  fname  1240©  "Nancy"  ;  mname  3059©  "J."  ;  lname  1241©  "McClellan" 

;  bdate  3060©  "14  Feb  57"  ;  ssn  990124444  ;  spouse  1238©  ""  ;  sptr  nil  ] 

x41:  1242©  addr[  street  3062©  "2331  Long  St."  ;  city  3063©  "Monterey"  ;  state  3064© 

"CA"  ;  Zip  3065©  "93940"  ] 


x42 
x43 
x44 


1243©  phone_number [  number  3061©  "(203)999-9991"  ] 

1244©  emp_tuple[  person  x40"  ;  address  x41"  ;  phone  x42"  ;  widget  nil  ] 

1221©  person!  fname  3066©  "Leonard"  ;  mname  3067©  "H."  ;  lname  1222©  "Tharpe' 


bdate  3068©  "12  Aug  58"  ;  ssn  110121212  ;  spouse  3069©  "Stephanie"  ;  sptr  nil  ] 
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city  2779®  "Monterey"  ;  state 


widget  nil  ] 
Iname  1371©  ""  ;  bdate  13720 


x45:  1223®  addr[  street  3071@  "432  Caldwell  Drive" 

30720  "CA"  ;  zip  3073®  "93940"  ] 

x46:  1224(1  phone_number  [  number  3070®  "(408)452-1234"  ] 

x47  :  1225®  emp_tuple[  person  x44"  ;  address  x45~  ;  phone  x46~  ;  widget  nil  ] 

x48:  1227®  person [  fname  3074®  "David"  ;  rnname  3075®  "M."  ;  lname  1228®  "Nash"  ; 

bdate  3076®  "21  Jul  65"  ;  ssn  23551324  ;  spouse  3077®  "Tammy"  ;  sptr  nil  ] 

x49:  1229®  addr [  street  3079®  "2112  Leidig  Circle"  ;  city  2778®  "Monterey"  ;  state 

3080®  "CA"  ;  zip  3081®  "93940"  ] 

x50:  1230®  phone_number [  number  3078®  "(408)123-4567"  ] 

x51 :  1231®  emp_tuple[  person  x48~  ;  address  x49~  ;  phone  x50 

x52  :  1368®  person!  fname  1369®  ""  ;  rnname  1370® 

""  ;  ssn  0  ;  spouse  1373®  ""  ;  sptr  nil  ] 

x53:  1374®  addr [  street  1375®  ""  ;  city  1376®  "" 

x54:  1379®  phone_number [  number  1380®  ""  ] 

x55:  1367®  emp_tuple[  person  x52~  ;  address  x53 

x56:  1132®  relation [  relation_name  1133®  "r2"  ; 

attribute_types  x39~  ;  tuples  1135®  <  x43~  x47~ 

1137®  "person  ->  ssn"  ] 

person"  ] 

addr"  ] 

phone_number"  ] 

diff_type"  ] 


state  1377® 


zip  1378® 


;  phone  x5  4~  ;  widget  nil  ] 
attribute_names  x38~  ; 
x51~  >  ;  tuple_type  x55~  ;  key 


1279®  name 

1281®  name 

1283®  name 

1285®  name 


x57 
x58 
x59 
x60 
x61 
bdate  3090®  "4  Jul  62" 


name  1288® 
name  1289® 
name  1290® 
name  1291® 


1139®  person!  fname  1140®  "Tim" 

ssn  22121212 


rnname  3  0  89®  "J." 
spouse  1138®  "" 
city  1144® 


'Kelly' 


;  lname  1141® 
;  sptr  nil  ] 
'Monterey"  ;  state  1145® 


x62  :  1142®  addr[  street  1143®  "345  Bergin" 

"CA"  ;  zip  3092®  "93940"  ] 

x63 :  1146®  phone_number [  number  3091®  "(408)123-4567"  ] 

x64:  1148®  emp_tuple[  person  x61~  ;  address  x62'"  ;  phone  x63"  ;  widget  nil  ] 

x65:  1150®  person  [  fname  1151®  "Ronald"  ;  mname  1152®  "L."  ;  lname  1153®  "Spear" 

;  bdate  3082®  "29  Dec  62"  ;  ssn  120926190  ;  spouse  3083®  "Karin"  ;  sptr  nil  ] 

x66:  1154®  addr[  street  3085®  "397B  Ricketts  Road"  ;  city  3086®  "Monterey"  ;  state 

3087®  "CA"  ;  zip  3088®  "93940"  ] 


X67 
x68 
x69 

x7  0 
x71 
x72 
x73 


1155®  phone_number [  number  3084®  "(408)375-8619 

1156®  emp_tuple[  person  x65~  ;  address  x66~  ;  phone  x67 

1384®  person [  fname  1385®  ""  ;  mname  1386® 

ssn  0  ;  spouse  1389®  ""  ;  sptr  nil  ] 

1390®  addr[  street  1391®  ""  ;  city  1392®  "" 

1395®  phone_number [  number  1396®  ""  ] 

1383®  emp_tuple[  person  x69~  ;  address  x70 

1157®  relation!  relation_name  1158®  "r3"  ; 


lname  1387® 


state  1393® 


widget  nil  ] 

""  ;  bdate  1388® 

;  zip  1394®  ""  ] 


attribute_types  1276@  <  x57' 


tuple_type  x72' 


x7  4 

x7  5 

x76 

x77 

x7  8 

x79 

x80 

x81 

X82 

x83 

x84 

x85 

x86 

x87 

x88 

x89 

x90 

x91 

x92 

x93 

x94 

x95 

ssn  0 

x96 

x97 

x98 


1163®  name 

1165®  name 

1167®  name 

1169®  name 

1171®  name 

1173®  name 

117  5®  name 

1177®  name 

1179®  name 

1181®  name 

1310®  name 

1312®  name 

1314®  name 

1316®  name 

1318®  name 

1320®  name 

1322®  name 

13  24®  name 

13  26®  name 

1328®  name 


key  1162® 
name  1164® 
name  1166® 
name  1168® 
name  1170® 
name  117  2® 


x58"  x59' 
'person 


x60~  > 
- >  ssn"  ] 
person  ->  fname" 
person  ->  mname" 

>  lname" 

>  bdate" 

>  spouse' 


;  phone  x71~  ;  widget  nil  ] 
attribute_names  x38~  ; 
tuples  1160®  <  x64~  x68"  >  ; 


'person 
'person 
'person 

name  117  4®  "addr  ->  street" 
name  117  6®  "addr  ->  city"  ] 
'addr  ->  state" 
'addr  ->  zip"  ] 
'phone  -  >  number 


name  117  8® 
name  1180® 
name  1182® 
name  1330®  "string' 
name  1331®  "string" 
name  1332®  "string" 
name  1333®  "string" 
name  1340®  "integer" 
name  133  5®  "string" 
name  1336®  "string" 
name  1337®  "string" 
name  1338®  "string" 
name  1339®  "string" 


1183®  "" 

1184®  person!  fname  x94~  ;  mname  x94' 

;  spouse  x94~  ;  sptr  nil  ] 
1186®  addr[  street  x94^  ;  city  x94~ 


lname  1185®  "Larson"  ;  bdate  x94' 


state  x94' 


zip  x94' 


1187®  phone_number [  number  x94' 

1188®  emp_tuple(  person  x95~  ;  address  x96^  ;  phone  x97^  ;  widget  nil 
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X99: 

X100: 

;  ssn 

xlOl 

xl02 

xl03 

xl04 

xl05 

X104 

X106 

X107 

X108 

xl09 

xllO 

xlll 

xll2 

xll3 

attri 

1206© 

xll4 

xll5 

X116 

11  ii 

xll7 

X118 

xll9 

X120 

attri 

;  key 

xl21 

xl22 

xl23 

xl24 

X125 

;  bda 

xl26: 

state 

xl27 

X128 

xl29 

xl30 

xl31 

X132 

X133 

attri 

>  ;  t 

xl34: 

xl35 

xl36 

X137 

xl38 

attri 

->  ss 

xl39 

xl40 

xl41 

X142 

xl43 

X144 

X145 

x!4 

X147 

X148 

x!49 


1189©  "" 

1190©  person[  fname  x99~  ;  mname  x99~  ;  lname  1191@  "Johnson"  ;  bdate  x99~ 

0  ;  spouse  x99~  ;  sptr  nil  1 

1192(1  addr[  street  x99~  ;  city  x99"  ;  state  x99"  ;  zip  x99~  ] 

1193©  phone_number (  number  x99~  ) 

1194©  emp_tuple[  person  xlOO^  ;  address  xl01~  ;  phone  xl02/s  ;  widget  nil  ] 

11950  "" 

1196®  person[  fname  xl04~  ;  mname  xl04~  ;  lname  11970  "Lombardo"  ;  bdate 

;  ssn  0  ;  spouse  xl04~  ;  sptr  nil  ] 

1198©  addr[  street  xl04"  ;  city  xl04/s  ;  state  xl04"  ;  zip  xl04~  ] 

1199©  phone_number [  number  xl04~  ] 

1200@  emp_tuple[  person  xl05~  ;  address  xl06~  ;  phone  xl07~  ;  widget  nil  ] 

1440©  person!  fname  1441@  ""  ;  mname  1442©  ""  ;  lname  1443©  ""  ;  bdate  1444© 
ssn  0  ;  spouse  1445©  ""  ;  sptr  nil  ] 

1446©  addr[  street  1447©  ""  ;  city  1448©  ""  ;  state  1449©  ""  ;  zip  1450©  ""  ] 

1451©  phone_number [  number  1452©  ""  ] 

1439©  emp_tuple[  person  xl09~  ;  address  xll0~  ;  phone  xlll~  ;  widget  nil  ] 

1201©  relation!  relation_name  1202©  "test2"  ;  attribute_names  xll4~  ; 
bute_types  xll5A  ;  tuples  1204©  <  x98~  xl03~  xlOS"  >  ;  tuple_type  xll2~  ;  key 

"person  ->  ssn"  ] 

1207©  <  x74~  x75~  x76~  x77~  x78"  x79"  x80~  x81"  x82"  x83A  > 

1307©  <  x84"  X85"  x86^  x87"  x88"  x89"  x90"  x91"  x92"  x93"  > 

1426©  person!  fname  1427©  ""  ;  mname  1428©  ""  ;  lname  1429©  ""  ;  bdate  1430© 
ssn  0  ;  spouse  1431©  ""  ;  sptr  nil  ] 

1432©  addr[  street  1433©  ""  ;  city  1434©  ""  ;  state  1435©  ""  ;  zip  1436©  ""  ] 

143  7©  phone_number [  number  14  38©  ""  ] 

1425©  emp_tuple[  person  xll6~  ;  address  xll7~  ;  phone  xll8 


1208©  relation!  relation_name  1209©  "TEMPT 
bute_types  xll5~  ;  tuples  1211©  <  x98/s  xl03~ 

1213©  "person  ->  ssn"  ] 

1295©  name!  name  1303©  "person"  ] 

1297©  name!  name  1304©  "addr"  ] 

1299©  name!  name'  1305©  "phone_number"  ] 

1301©  name!  name  1306©  "idl_univ"  ] 

1215©  person!  fname  3093©  "James"  ;  mname  3094©  "S." 
te  3095©  "12  Jan  85"  ;  ssn  550121212  ;  spouse  1214© 


widget  nil 
;  attribute_names  xll4~  ; 
xl08~  x64~  >  ;  tuple_type  xll9' 


city  2780©  "Fayetteville" 


1217©  addr!  street  3097©  "41112  Lost  Lane" 
3098©  "NC"  ;  zip  3099©  "32212"  ] 

1218©  phone_number[  number  3096©  "(231)222-3333"  ] 
1219©  emp_tuple!  person  xl25~  ;  address  xl26~  ;  phone  xl27 
1398©  person!  fname  1399©  ""  ;  mname  1400©  ""  ;  lname  1401© 
ssn  0  ;  spouse  1403©  ""  ;  sptr  nil  ] 
1404©  addr[  street  1405©  ""  ;  city  1406©  ""  ;  state  1407©  "" 
1409©  phone_number [  number  1410©  ""  ] 
1397©  emp_tuple[  person  xl29~  ;  address  xl30~  ;  phone  xl31 


lname  1216©  "Baumann" 
sptr  nil  ] 


attribute_names  x38~  ; 
;  tuples  1235©  <  X128"  x47 


widget  nil  ] 
;  bdate  1402© 

zip  14  08©  ""  ] 

widget  nil  ] 

x51" 


;  lname  1415©  "" 
state  1421©  ""  ; 


;  bdate  1416© 
zip  1422©  ""  ] 
:  widget  nil  ] 


1232©  relation!  relation_name  1233©  "r4"  ; 
bute_types  1292©  <  xl21"  xl22"  xl23"  xl24"  > 
uple_type  xl32/N  ;  key  1237©  "person  ->  ssn" 

1412©  person!  fname  1413©  ""  ;  mname  1414©  " 
ssn  0  ;  spouse  1417©  ""  ;  sptr  nil  ] 

1418©  addr[  street  1419©  ""  ;  city  1420©  "" 

1423©  phone_number [  number  1424©  ""  ] 

1411©  emp_tuple[  person  xl34~  ;  address  xl35~  ;  phone  xl36' 

1245©  relation!  relation_name  1246©  "r5"  ;  attribute_names  x38~  ; 
bute_types  x39~  ;  tuples  1248©  <  x43~  >  ;  tuple_type  xl37~  ;  key  1250©  "person 
n"  ] 

1501©  name!  name  1518©  "Employee  SSN"  ] 

150  3©  name!  name  1519©  "Project  Number"  ] 

1505©  name!  name  1520©  "Hours  Worked"  ] 

1510©  name!  name  1521©  "integer"  ] 

1512©  name!  name  1522©  "integer"  j 

1514©  name!  name  1523©  "rational"  ] 

1526©  proj_tuple[  essn  120926190  ;  proj_num  2  ;  hours  10.0  ] 

1529©  proj_tuple[  essn  999999999  ;  proj_num  1  ;  hours  45.2  ] 

1532©  proj_tuple[  essn  123456789  ;  proj_num  2  ;  hours  51.5  ] 

1535©  proj_tuple[  essn  987654321  ;  proj_num  30  ;  hours  4.0  ] 


1497©  proj_tuple[  essn  0  ;  proj_num  0 


hours  0.0 
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X150: 

xi4cr 

xl46* 

xl51 

xl52 

xl53 

xl54 

xl55 

xl56 

xl57 

xl58 

xl59 

xl60 

X161 

xl52 

xl58 

xl62 

X163 

X164 

xl65 

xl66 

X167 

X168 

xl69 

xl70 

xl71 

xl72 

xl73 

xl74 

X175 

xl76 

X177 

xl78 

xl79 

X180 

12212 

xl81 

xl82 

X183 

xl84 

xl85 

xl86 

xl87 

xl88 

nil 

X189 

12212 

X190: 

X191: 

X192: 

nil  ; 

X193: 

12212 

X194 

X195 

X196 

nil 

xl97 

12212 

X198 

X199 

x200 

nil 

X201 

X202 

x203 

x204 


1490© 
xl41~ 
xl47~ 
15540 
15560 
15580 
15600 
15620 
1564® 
15680 
15710 
15740 
15470 
15400 
xl53" 
xl59" 
16180 
16200 
16220 
1624© 
16260 
1628© 
1630© 
1635© 
1637© 
1639© 
1641© 
1643© 
1645© 
1647© 
3012© 
3013© 
1073© 
3014© 
3210© 

1212  ; 
3017© 
3018© 
3019© 
3020© 
3211© 
3016© 
3212© 
32090 
essn 
32250 

1212  ; 
32260 
32270 
32240 
essn 
32400 

1212  ; 
3241© 
3242© 
32390 
essn 
3255© 

1212  ; 
3256© 
3257© 
3254© 
essn 
30210 
30220 
10790 
30230 


relation!  relation_name  1495©  "ptl"  ;  attribute 

>  ;  attribute_types  15070  <  xl42~  xl43~  xl44~  >  ; 
xl48"  >  ;  tuple_type  xl49"  ;  key  14960  "essn,pr 
name [  name  15750  "Employee  SSN"  ] 

'Project  Number"  ] 

'Hours  Worked"  ] 

'integer"  ] 

'integer"  ] 

'rational"  ] 

hour 
hours 
hours 
0  ] 
relation!  relation_name  1545©  "pt2"  ;  attribute 

>  ;  attribute_types  1551©  <  xl54"  xl55~  xl56~  >  ; 

>  ;  tuple_type  xl60~  ;  key  15460  "essn, proj_num 


names 

tuples 

oj_num" 


1498©  <  xl39* 
1494©  <  xl45" 


name [  name  157  6© 
name [  name  1578© 
name [  name  1579© 
name [  name  15800 
name [  name  15  810 
proj_tuple[  essn  550926190 
proj_tuple[  essn  666666666 
proj_tuple[  essn  123456789 
proj_tuple[  essn  0 


proj_num  2  3 
proj_num  2  ; 
proj_num  1  ; 
proj_num  0  ;  hours  0 


s  34  .4 
15.0  ] 
24.0  ] 

.names 
tuples 


15480  <  xl51' 
15440  <  xl57' 


name  16  580 
name  16590 


"Person"  ] 
"Address"  ] 
"Phone"  ] 
"Widget"  ] 
"Employee  SSN"  ] 
"Project  Number" 
"Hours  Worked"  ] 
"person"  ] 
"addr"  ] 

"phone_number"  ] 
"idl_univ"  ] 
"integer"  ] 
"integer"  ] 
name  16  680  "rational"  1 


name  16  60© 
name  1661© 
name  16  55© 
name  16  57© 
name  16  56© 
name  16  62© 
name  16  63© 
name  1664© 
name  16  65© 
name  16  66© 
name  1667© 


name  [ 

name  [ 

name  [ 

name  [ 

name  [ 

name  [ 

name  [ 

name  [ 

name  [ 

name  [ 

name  [ 

name  [ 

name  [ 

name  [ 

"Mathew" 

"James" 

"Rothlisberger" 

"23  Feb  60" 

person [  fname  xl7  6"  ;  mname  xl77 

spouse  3208©  ""  ;  sptr  nil  ] 

"231  Bergen" 

"Monterey" 

"CA" 

"93940" 

addr[  street  xl81~  ;  city  xl82~ 

"  (408)375-1234" 

phone_number [  number  xl86~  ] 
cartl_result_tuple [  person  xl80~  , 
550926190  ;  proj_num  2  ;  hours  10 

person[  fname  xl76~  ;  mname  xl77 

spouse  3223©  ""  ;  sptr  nil  ] 

addr[  street  xl81~  ;  city  xl82^ 

phone_number [  number  xl86"  ] 
cartl_result_tuple [  person  xl89 
999999999  ;  proj_num  1 

person [  fname  xl7  6~  ;  mname  xl77 

spouse  3238©  ""  ;  sptr  nil  ] 

addr[  street  xl81A  ;  city  X182" 

phone_n umber [  number  xl86^  ] 
cartl_result_tuple [  person  xl93~  ; 
123456789  ;  proj_num  2  ;  hours  51.5 

person[  fname  xl76~  ;  mname  xl77~ 

spouse  3253©  ""  ;  sptr  nil  ] 

addr[  street  xl81~  ;  city  xl82/N  ;  state  xl83 

phone_number [  number  xise^  ] 
cartl_result_tuple [  person  xl97~  ; 
987654321  ;  proj_num  30  ;  hours  4 

"Leonard" 

"H." 

"Tharpe" 

"12  Aug  58" 


lname  xl78~  ;  bdate  xl79~  ;  ssn 


state  xl83' 


address  xl85~ 
0  ] 
'  ;  lname  xl78' 

state  xl83~  , 

address  xl90" 
hours  45.2  ] 

;  lname  xl7  8' 

state  xl83~  ; 

address  xl94~ 

lname  xl78' 


address  xl98~ 
0  ] 


zip  xl84~  ] 

phone  xlS?^  ;  widget 

;  bdate  xl7  9~  ;  ssn 

zip  xl84~  ] 

phone  xl91~  ;  widget 

;  bdate  Xl7  9~  ;  ssn 

zip  xl84~  ] 

phone  xl95~  ;  widget 

;  bdate  xl79~  ;  ssn 

zip  xl84/v  ] 

phone  xl99~  ;  widget 


180 


x205 

3270® 

110121212  ; 

X206 

3026® 

X207 

3027® 

x208 

3028® 

X209 

3029® 

x210 

3271© 

x211 

3025® 

x212 

3272® 

x213 

3269® 

nil 

essn 

x214 

3285® 

1101; 

21212  ; 

x215 

3286® 

x216 

3287® 

x217 

3284® 

nil 

essn 

X218 

3300® 

1101; 

21212  ; 

x219 

3301® 

X220 

3302® 

x221 

3299® 

nil  , 

essn 

x222 

3315® 

1101; 

21212  ; 

X223 

3316® 

X224 

3317® 

X225 

3314® 

nil  , 

essn 

x226 

3030® 

X227 

3031® 

X228 

1085® 

X229 

3032® 

x2  3  0 

3330® 

2201: 

21212  ; 

X231 

3035® 

x232 

3036® 

x233 

3037® 

X234 

3038® 

X235 

3331® 

x236 

3034® 

x237 

3332® 

X238 

3329® 

nil 

essn 

X239 

3345® 

2201; 

21212  ; 

X240 

3346® 

x2  41 

3347® 

x242 

3344® 

nil 

essn 

x243 

3360® 

2201; 

21212  ; 

x244 

3361® 

x245 

3362® 

X246 

3359® 

nil 

essn 

x247 

3375® 

2201; 

21212  ; 

X248 

3376® 

x2  4  9 

3377® 

x250 

3374® 

nil 

essn 

x251 

1091® 

X252 

1092® 

X253 

1093® 

x254 

3039® 

x255 

3390® 

1209; 

26190  ; 

person [  fname  x201 
spouse  3  2  68®  ""  ;  s 
"432  Caldwell  Drive 
"Monterey" 
"CA" 
"93940" 

addr[  street  x206" 
"  (408)452-1234" 
phone_number [  numbe 
cartl_result_tuple [ 
550926190  ;  proj_num 
personf  fname  x201~ 
spouse  3  2  83®  ""  ;  s 
addr(  street  x206" 
phone_number [  numbe 
cartl_result_tuple ( 
999999999  ;  proj_num 
person[  fname  x201~ 
spouse  32  98®  ""  ;  s 
addr[  street  x206~ 
phone_number [  numbe 
cartl_result_tuple [ 
123456789  ;  proj_num 
person!  fname  x201" 
spouse  3313®  ""  ;  s 
addr[  street  x206~ 
phone_number [  numbe 
cartl_result_tuple [ 
987654321  ;  proj_num 
"Charles" 
"  L .  " 

"Baumann" 
"23  Jun  54" 
person[  fname  x226~ 
spouse  3  3  28®  ""  ;  s 
"12345  General  Lane 
"Ft  Bragg" 
"NC" 
"1623  4" 

addr[  street  x231~ 
"  (122)324-9876" 
phone_number [  numbe 
cartl_result_tuple [ 
550926190  ;  proj_num 
person[  fname  x226~ 
spouse  3  3  43®  ""  ;  s 
addr[  street  x231~ 
phone_number [  numbe 
cartl_result_tuple [ 
999999999  ;  proj_num 
person!  fname  x226~ 
spouse  3  3  58®  ""  ;  s 
addr [  street  x231~ 
phone_number [  numbe 
cartl_result_tuple ( 
123456789  ;  proj_num 
person!  fname  x226" 
spouse  3373®  ""  ;  s 
addr[  street  x231~ 
phone_number [  numbe 
cartl_result_tuple [ 
987654321  ;  proj_num 
"Ronald" 
"  L .  " 
"Spear" 
"29  Dec  62" 
person[  fname  x251~ 
spouse  3  3  88®  "" 


mname  x202"  ;  lname  x203~  ;  bdate  x204' 
ptr  nil  ] 


ssn 


;  city  x207~ 

state  x208~  ; 

zip  x209~  ] 

r  x211"  ] 

person  x205~  ; 

address  x210~  ; 

phone  x212"  ; 

widget 

2  ;  hours  10 

0  ] 

;  mname  x20  2~  ;  lname  x20  3~ 

;  bdate  x204" 

;  ssn 

ptr  nil  ] 

;  city  x207~  , 

state  x208"  ; 

zip  x209~  ] 

r  x211A  ] 

person  x214~  ; 

address  x215~  ; 

phone  x216~  ; 

widget 

1  ;  hours  4  5 

2  ] 

;  mname  x20  2~  ;  lname  x20  3~ 

;  bdate  x204" 

;  ssn 

ptr  nil  ] 

;  city  x207~ 

state  x208"  ; 

zip  x209~  ] 

r  x211"  ] 

person  x218/s  ; 

address  x219~  ; 

phone  x220~  ; 

widget 

2  ;  hours  51 

5  ] 

;  mname  x20  2"  ;  lname  x203~ 

;  bdate  x20  4~ 

;  ssn 

ptr  nil  ] 

;  city  x207~ 

state  x208"  ; 

zip  x209~  ] 

r  x211A  ] 

person  x222"  ; 

address  x223~  ; 

phone  x224~  ; 

widget 

3  0  ;  hours  4 

0  ] 

mname  x227~  ;  lname  x22  8"  ;  bdate  x22  9' 
ptr  nil  ] 


ssn 


;  city  x23  2~ 

state  x233/s  ; 

zip  x234~  ] 

r  x236A  ] 

person  x2  3  0~  ; 

address  x235~  ; 

phone  x23  7"  ; 

widget 

2  ;  hours  10 

0  ] 

;  mname  x22  7~  ;  lname  x22  8'v 

;  bdate  x229" 

;  ssn 

ptr  nil  ] 

;  city  x232~ 

state  x233"  ; 

zip  x234~  ] 

r  x2  36"  ] 

person  x239~  ; 

address  x2  40~  ; 

phone  x2  41"  ; 

widget 

1  ;  hours  4  5 

2  ] 

;  mname  x227~  ;  lname  x228~ 

;  bdate  x22  9~ 

;  ssn 

ptr  nil  ] 

;  city  x23  2" 

state  x233~  ; 

zip  x234~  ] 

r  x236A  ] 

person  x2  43~  ; 

address  x2  44~  ; 

phone  x24  5~  ; 

widget 

2  ;  hours  51 

5  ] 

;  mname  x227~  ;  lname  x22  8~ 

;  bdate  x229~ 

;  ssn 

ptr  nil  ] 

;  city  x23  2~ 

state  x233/s  ; 

zip  x234~  ] 

r  X236"  ] 

person  x2  47~  ; 

address  x2  48~  ; 

phone  x249~  ; 

widget 

3  0  ;  hours  4 

0  ] 

;  mname  x2  52~  ;  lname  x253~  ;  bdate  x2  54' 
ptr  nil  ] 


ssn 
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x256:  3042®  "397B  Ricketts  Road" 

x257:  3043®  "Monterey" 

X258:  3044®  "CA" 

x259:  3045®  "93940" 

x260:  3391®  addr[  street  x256"  ;  city  x257 

X261:  3  041®  "(408)37  5-8  619" 

x262:  3392®  phone_number [  number  x261"  ] 

x263:  3389®  cartl_result_tuple [  person  x255 

nil  ;  essn  550926190  ;  proj_num  2  ;  hours 

x264:  3405®  person[  fname  x251"  ;  mname  x2 
120926190  ;  spouse  3403®  ""  ;  sptr  nil  ] 

x265:  3406®  addr[  street  x256~  ;  city  x257 

x2  66:  3407®  phone_number [  number  x2  61"  ] 

x267:  3404®  cart l_result_tuple [  person  x264 

nil  ;  essn  999999999  ;  proj_num  1  ;  hours 

x268:  3420®  person!  fname  x251/s  ;  mname  x2 
120926190  ;  spouse  3418®  ""  ;  sptr  nil  ] 

x269:  3421®  addr [  street  x256"  ;  city  x257 

x270:  3422®  phone_number [  number  x261~  ] 

x271:  3419®  cartl_result_tuple[  person  x268 

nil  ;  essn  123456789  ;  proj_num  2  ;  hours 

x272:  3435®  person[  fname  x251~  ;  mname  x2 
120926190  ;  spouse  3433®  ""  ;  sptr  nil  ] 

x273:  3436®  addr [  street  x256~  ;  city  x257 

x274:  3437®  phone_number [  number  x2  61~  ] 

x275:  3434®  cart l_result_tuple [  person  x272 

nil  ;  essn  987654321  ;  proj_num  30  ;  hours 

x276:  1099®  "Jon" 

x277:  1100®  "Lewis" 

x278:  1101®  "Spear" 

X27  9:  3  04  6®  "16  Sep  58" 

x280:  3450®  person [  fname  x276"  ;  mname  x2 
123456789  ;  spouse  3448®  ""  ;  sptr  nil  ] 

x281:  3048®  "3122  Apt  B  Sunset  Strip" 

x282:  1103®  "Redondo  Beach" 

x283:  1104®  "CA" 

x284:  3049®  "99812" 

x285:  3451®  addr[  street  x281~  ;  city  x282 

x286:  3047®  "(301)322-2341" 

x287:  3452®  phone_number [  number  x286"  ] 

x288:  3449®  cartl_resul t_tuple [  person  x280 

nil  ;  essn  550926190  ;  proj_num  2  ;  hours 

x289:  3465®  person[  fname  x276~  ;  mname  x2 
123456789  ;  spouse  3463®  ""  ;  sptr  nil  ] 

x290:  3466®  addr[  street  x281"  ;  city  x282 

x291:  3467®  phone_number  [  number  x2  8  6/v  ] 

x292:  3464®  cartl_result_tuple [  person  x289 

nil  ;  essn  999999999  ;  proj_num  1  ;  hours 

x293:  3480®  person[  fname  x276~  ;  mname  x2 
123456789  ;  spouse  3478®  ""  ;  sptr  nil  ] 

x294:  3481®  addr[  street  x281~  ;  city  x282 

x295:  3482®  phone_number [  number  x286"  ] 

x296:  3479®  cart l_result_tuple [  person  x293 

nil  ;  essn  123456789  ;  proj_num  2  ;  hours 

x297:  3495®  person [  fname  x276~  ;  mname  x2 
123456789  ;  spouse  3493®  ""  ;  sptr  nil  ] 

x298:  3496®  addr [  street  x281~  ;  city  x282 

x299:  3497®  phone_number (  number  x286~  ] 

x300:  3494®  cart l_result_tuple [  person  x297 

nil  ;  essn  987654321  ;  proj_num  30  ;  hours 

x301:  3050®  "Jon" 

X302:  3051®  "K." 

x303:  1352®  "Walter" 

x304:  3052®  "24  Dec  61" 

x305:  3510®  person!  fname  x301"  ;  mname  x3 
991221234  ;  spouse  3508®  ""  ;  sptr  nil  ] 

x306:  3055®  "3321  City  St." 

x307:  3056®  "Marina" 


state  x258' 


address  x260" 
0  ] 
•  ;  lname  x25  3' 

state  x258^  , 

address  x2  65" 
2  ] 
'  ;  lname  x253' 

state  x258" 

address  x2  69" 
5  ] 
'  ;  lname  x2  53' 

state  x258/N 

address  x273~ 
0 


zip  x259~  ] 

phone  x262~  ;  widget 

;  bdate  x254~  ;  ssn 

zip  x259"  ] 

phone  x266~  ;  widget 

;  bdate  x254~  ;  ssn 

zip  x259~  ] 

phone  x27  0"  ;  widget 

;  bdate  x2  5  4"  ;  ssn 

zip  x259"  ] 

phone  x27  4"  ;  widget 


4.0  ] 


77"  ;  lname  x278"  ;  bdate  x279' 


ssn 


45 
77' 


state  x283' 


address  x285' 
0  ] 
v  ;  lname  x27( 

state  x283" 

address  x290' 
2  ] 
v  ;  lname  x27i 

state  x283" 

address  x294' 
5  ] 
"  ;  lname  x27l 

state  x283" 

address  x298' 
0  ] 


zip  x284"  ] 

phone  x287"  ;  widget 

;  bdate  x27  9"  ;  ssn 

zip  x284"  ] 

phone  x291"  ;  widget 

;  bdate  x27  9~  ;  ssn 

zip  x284"  ] 

phone  x295"  ;  widget 

;  bdate  x279"  ;  ssn 

zip  x284"  ] 

phone  x299~  ;  widget 


02"  ;  lname  x303"  ;  bdate  x304' 


ssn 


182 


x308 

x309 

x310 

x311 

x312 

x313 

nil 

x314 


3057©  "CA" 

3058©  "93940" 

3511©  addr[  street  x306~  ;  city  x307~  ;  state  x308"  , 

3054©  "(408)122-4253" 

3  512©  phone_number [  number  x311~  ] 

3509©  cartl_result_tuple [  person  x305~  ;  address  x310~ 

essn  550926190  ;  proj_num  2  ;  hours  10.0  ] 

lname  x303' 


zip  x309~  ] 


phone  x312~  ;  widget 


bdate  x304' 


;sn 


x316 
x317 

nil 
x318 


x320 
x321 
nil 
x322 


state  x308~ 

address  x315~ 
2  ] 
•  ;  lname  x303' 

state  x308" 

address  x319~ 
5  ] 
'  ;  lname  x303" 

state  x308" 


zip  x309"  ] 
phone  x316~  ; 
;  bdate  x304' 


widget 


3525©  person [  fname  x301~  ;  mname  x302 
991221234  ;  spouse  3523©  ""  ;  sptr  nil  ] 
x315:  3526©  addr [  street  x306"  ;  city  x307" 

3  527©  phone_number [  number  x311"  ] 

3524©  cartl_result_tuple [  person  x314~  ; 

essn  999999999  ;  proj_num  1  ;  hours  45 

3540©  person[  fname  x301~  ;  mname  x302 
991221234  ;  spouse  3538©  ""  ;  sptr  nil  ] 
x319:  3541©  addr[  street  x306~  ;  city  x307~ 

3  542©  phone_number  [  number  x311/v  ] 

3539©  cartl_result_t.uple  [  person  x318~  ; 

essn  123456789  ;  proj_num  2  ;  hours  51 

3  555©  person!  fname  x301~  ;  mname  x302 
991221234  ;  spouse  3553©  ""  ;  sptr  nil  ] 
x323:  3556©  addr [  street  x306"  ;  city  x307" 

3  557©  phone_number [  number  x311~  ] 

3554©  cartl_result_tuple [  person  x322~  , 

essn  987654321  ;  proj_num  30  ;  hours  4 

1670©  person [  fname  1671©  ""  ;  mname  1672© 
ssn  0  ;  spouse  167  5©  ""  ;  sptr  nil  ) 

1676©  addr[  street  1677©  ""  ;  city  1678©  " 

1681©  phone_number[  number  1682©  ""  ] 

1669©  cartl_result_tuple [  person  x326~  ;  address  x327 

essn  0  ;  proj_num  0  ;  hours  0.0  ] 

1605©  relation!  relation_name  1610©  "Cart  Resultl"  ;  attribute_names  1615© 
xl63~  xl64"  xl65~  xl66"  xl67"  xl68"  >  ;  attribute_types  1632©  <  xl69~  xl70~ 


x324: 
X325: 
nil  ; 
X326: 

X327: 
X328: 
x329: 
nil  ; 
X330: 
<  xl62 
Xl71~  xl72' 
X217"  x221' 
x300"  x313' 


address  x323 
0  ] 

;  lname  167  3© 


zip  x309~  ] 

phone  x320~  ;  widget 

;  bdate  x30  4~  ;  ssn 

zip  x309~  ] 

widget 


Dhone  x324' 


bdate  1674© 


state  1679© 


;  zip  1630©  ""  ] 
phone  x328"  ;  widget 


x331 
x332 
x333 
x334 
x3  3  5 
x336 
x3  3  7 
x338 
x3  3  9 
x331 
X337 
x340 
x341 
x342 
;  att 

""  ] 

X343 
x344 
x345 

x346 

x347 

X348 

x349 

X350 

X3  51 

x352 

X343 

nil 

x353 


2793© 
2795© 
2800© 
2802© 
2809© 
2815© 
2818© 
2806© 
2784© 
x332~ 
>  ;  t 
2830© 
2826© 
2819© 
ribute 


xl73"  xl74"  xl75~  >  ;  tuples  3197©  <  xl88"  xl92~  xl96~  x200~  x213" 
x225~  x238~  x242"  x246~  x250~  x263~  x267~  x271~  x275~  x288~  x292"  x296' 
x317"  x321~  x325~  >  ;  tuple_type  x329"  ;  key  1611©  "ssn, essn, pro j_num* 

name [  name  27  97©  "Hours  Worked"  ] 
name [  name  27  98©  "Employee  SSN"  ] 
name [  name  2804©  "rational"  ] 
name [  name  28  05©  "integer"  ] 
projectl_result_tuple [  hours  20.4 
projectl_result_tuple [  hours  3.2  ; 
projectl_result_tuple [  hours  67.25 
projectl_result_tuple [  hours  0.0  ;  essn  0 
relation!  relation_name  2887©  "project  1" 
>  ;  attribute_types  2799©  <  x333"  x334~  >  ; 
uple_type  x338~  ;  key  2791©  "essn"  ] 
proj_tuple[  essn  550926190  ;  proj_num  2  ; 


essn  550926190 
essn  123456789  ] 
;  essn  987654321 


;  attribute_names  2792©  < 
tuples  2788©  <  x335~  x336~ 

hours  2  0.0  ] 


proj_tuple[  essn  0  ;  proj_num  0  ;  hours  0.0  ] 

relation!  relation_name  2825©  "comp  obj"  ;  attribute_names  2821©  <  > 


_types  2822©  <  >  ;  tuples  2823©  <  x340~  >  ;  tuple_type  x341' 


key  2  82  4© 


state  2845©  " 
;  lname  2  851© 

state  2857©  '" 


2838©  name[  name  2839©  ""  ] 
2842©  addr[  street  2843©  ""  ;  city  2844©  "' 
2848©  person[  fname  2849©  ""  ;  mname  2850© 
ssn  0  ;  spouse  2853©  ""  ;  sptr  nil  ] 
2854©  addr[  street  2855©  ""  ;  city  2856©  "' 
2859©  phone_number[  number  2860©  ""  ] 

2847©  emp_tuple[  person  x345~  ;  address  x346~  ;  phone  x347' 
2861©  proj_tuple[  essn  0  ;  proj_num  0  ;  hours  0.0  ] 
2840©  result_tuple[  values  2841©  <  x344~  x348"  x349~  >  ] 
2862©  result_tuple[  values  2863©  <  >  ] 

2832©  relation!  relation_name  2837©  "result  test"  ;  attribute_names  2833©  < 
>  ;  attribute_types  2835©  <  >  ;  tuples  2836©  <  x350~  x351"  >  ;  tuple_type 
key  2  831©  ""  ] 
1112©  "person  ->  ssn" 


zip  2846©  ""  ] 
;  bdate  2852© 

zip  2858©  ""  ] 

;  widget  nil  ] 
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x354:  3563©  relation!  relation_name  3  5640  "lTEMP_rl .  r4"  ;  attribute_names  3565(3  < 
xl~  x2~  x3~  x4~  >  ;  attribute_types  x39"  ;  tuples  35660  <  xl2~  xl6~  x20~  x24"  x28~ 
x32~  xl28/v  x51A  >  ;  tuple_type  x36~  ;  key  x353~  ] 

x355:  12510  database!  name  28640  "Relational  Address  DB"  ;  relations  12530  <  x37~ 
x56"  x73"  X113"  xl2CT  xl33~  xl38~  xl5CT  xl61~  x33CT  x339"  x342"  x352"  x354"  >  ] 
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APPENDIX  E:  MODIFIED  R/OODBMS  SCHEMA 


******************************************************************************** 
A  Modified  Relational/Object-Oriented  Database  Management  System 


************ 


*************** 


-Description  :  This  file  contains  the  IDL  schema  for  the  implementation  of 
A  Modified  Relational/Object-Oriented  Database  Management 
System.  Of  the  five  primitive  relational  algebra  operations 
(union,  difference,  project,  select,  and  Cartesian  product), 
the  project  and  Cartesian  product  operations  have  been  modified 
from  the  original  R/OODBMS  implemented  in  IDB. 


structure  relational  root  database  is 

****************************************************************************** 


database  =>    name 

relations 

database  ->    new_relation ( * ) ; 


:  string, 

:  seq  of  relation; 


relation  => 


relation  -> 
relation  -> 


relation_name 

attribute_names 

attribute_types 

tuples 

tuple_type 

key 


string, 

seq  of  name, 

seq  of  name, 

seq  of  tuple, 

tuple, 

string; 


new_tuple ( *  )  , 

check_union_compat ability (relation, relation)  =>  boolean; 

union (* ) , 
projection! * ) , 
difference ( * ) , 
Cartesian_product (* ) , 
selection ( * ) ; 


name  => 


name 


string; 


tuple  ->       equal_to (tuple, tuple, integer) 
less_than (tuple, tuple, integer) 
greater_than(tuple, tuple, integer) 

initialize_tuple (tuple) 
insert_f ields (relation, relation) 


=>  boolean, 
=>  boolean, 
=>  boolean, 

=>  tuple, 
=>  relation, 


insert  fieldsb  (relation, relation,index_array)  =>  relation, 

--  the  b  extension  indicates  modified  methods  used  in  this 
--  implementation. 

insert_tuples (relation, relation, relation)  =>  relation, 

insert  tuples  _b(relation, relation, relation)      =>  relation; 
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tuple  ::=       emp_tuple  I 
proj_tuple  I 
cartl_result_tuple  I 
projectl_result_cuple  I 
resulttuple  | 
nil; 

--  in  this  implementation,  result_tuple  is  the  only  tuple 
--  that  needs  to  be  defined  for  creating  resultant  relations 
--  in  both  the  project  and  Cartesian  product  operations.  Thus, 
--  cartl_result_tuple  and  projectl_result_tuple  are  not  needed 
--  in  this  implementation.  However,  they  have  been  left  in  so 
--  the  reader  could  more  easily  compare  this  schema  with  that 
--of  the  standard  R/OODBMS  schema. 

.****************************************************************************** 

for  database. new_relation  use  browser_visible; 

for  relation . new_tuple  use  browser_visible; 

for  relation. union  use  browser_visible; 

for  relation .Cartesian_product  use  browser_visible; 

for  relation. difference  use  browser_visibie; 

for  relation .projection  use  browser_visible; 

for  relation .selection  use  browser_visible; 

for  database . relations  use  linked; 
for  relation. tuples  use  linked; 

.**************************************************************** 

for  database . idl_key  use  bind(database_key) ; 
for  database  .  idl_print  use  bind(database_print )  ,- 
for  database .new_relation  use  bind (create_relation) ; 

for  relation. idl_key  use  bind ( relation_key ) ; 

for  relation. idl_print  use  bind(relation_print ) ; 

for  relation .new_tuple  use  bind(create_tuple) ; 

for  relation. check_union_compatability  use  bind(ck_union_compatability ) 

for  relation .union  use  bind(union_op) ; 

for  relation .Cartesian_product  use  bind(cart_prod_op) ; 

for  relation. difference  use  bind (set_dif f_op) ; 

for  relation .projection  use  bind (pro ject_op) ; 

for  relation . selection  use  bind(select_op) ; 

for  name.idl_key  use  bind(name_key ) ; 
for  name  .  idl_print  use  bind  (name_print )  ,- 

for  tuple. equal_to  use  bind(equal_to) ; 

for  tuple. less_than  use  bind(less_than) ; 

for  tuple. greater_than  use  bind (greater_than) ; 

for  tuple. initialize_tuple  use  bind( initialize_tuple) ; 
for  tuple. insert_f ields  use  bind ( insert_f ields ) ; 
for  tuple. insert_tuples  use  bind (insert_tuples) ; 


************** 


for  tuple.insertfieldsb  use  bind(insertfieldsb); 
for  tuple.inserttuplesb  use  bind(inserttuplesb); 


.*************************************  pyrin   hynlp*********** 

emp_tuple  =>         person    :   person, 

address   :   addr, 
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********************* 


phone 

phone_number 

widget 

idl_univ; 

person  => 

fname 

string, 

mname 

string, 

lnarne 

string, 

bdate 

string, 

ssn 

integer, 

spouse 

string, 

sptr 

person_nil ; 

person_nil  : : 

=  person  1  nil; 

addr  => 

street 

string, 

city 

string, 

state 

string, 

zip 

string; 

p ho ne_n umber  => 

number 

s  t  r  i  ng ; 

.*****************************' 


******************************* 


for  emp_tuple. idl_key  use  bind (emp_tuple_key ) ; 

for  emp_tuple. idl_print  use  bind (emp_tuple_print ) ; 

for  emp_tuple. equal_to  use  bind (emp_equal_to) ; 

for  emp_tuple . less_than  use  bind (emp_less_than) ; 

for  emp_tuple.greater_than  use  bind (emp_greater_than) ; 

for  emp_tuple . initialize_tuple  use  bind( initialize_emp_tuple) ; 

for  emp_tuple.insert_fields_b  use  bind(insert_emp_fields_b); 

for  person. idl_key  use  bind(person_key) ; 
for  person.  idl_print  use  bind(person_print)  ,- 

for  addr.idl_key  use  bind(addr_key ) ; 
for  addr . idl_print  use  bind(addr_print ) ; 

for  phone_number . idl_print  use  bind(phone_number_print ) ; 


.*********************************■ 


rproj_tuple*** 


***************************** 


proj_tuple  => 


essn 

proj_num 

hours 


integer, 
integer, 
rational; 


****************************************************************************** 

for  proj_tuple . idl_key  use  bind (proj_tuple_key ) ; 

for  proj_tuple . idl_print  use  bind(proj_tuple_print ) ; 

for  proj_tuple .equal_to  use  bind (pro j_equal_to) ; 

for  proj_tuple . less_than  use  bind(proj_less_than) ; 

for  proj_tuple .greater_than  use  bind (pro j_greater_than) ; 

for  proj_tuple . initialize_tuple  use  bind(initialize_proj_tuple) ; 


,****************************• 


rcartl_result_tuple1 


******************* 


cartl_result_tuple  => 


person 

address 

phone 

widget 

essn 

proj_num 

hours 


person, 

addr, 

phone_number, 

idl_univ, 

integer, 

integer, 

rational ; 


****************************************************************************** 

for  cartl_result_tuple .idl_key  use  bind(cartl_result_tuple_key ) ; 
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for  cartl_result_tuple . idl_print  use  bind ( cart l_result_tuple_print ) ; 
for  cartl_result_tuple . initialize_tuple  use 

bind(initialize_cartl_resul_tuple) ; 
for  cartl_result_tuple . insert_tuples  use  bind( insert_cartl_result_tuples ) ; 

****************************************************************************** 

projectl_result_tuple    =>  hours  :   rational, 

essn   :   integer; 

****************************************************************************** 

for  projectl_result_tuple. idl_key  use  bind (pro jectl_result_tuple_key ) ; 
for  projectl_result_tuple. idl_print  use  bind (projectl_result_tuple_print )  ; 
for  projectl_result_tuple. initialize_tuple  use 

bind(initialize_projectl_resul_tuple) ; 
for  projectl_result_tuple . insert_f ields  use  bind ( insert_projectl_result_f Ids ) ; 

****************************************************************************** 

resulttuple         =>  values    rseqofany; 

r*************************** 

for  resulttuple.  values  use  linked; 

.*************************************M1qh************************************* 

--  index_array  is  used  by  the  project  operation  to  hold  a  list  of  indexes 

--  to  the  attributes  of  a  relation  that  are  to  be  projected.  It  cannot  be 

--  reached  from  the  database  root  and  therefore  can  never  be  stored  in  the 

--  database  by  accident.  It  is  purely  set  up  as  a  data  structure  to  allow 

--  the  indexes  to  be  passed  as  a  parameter  in  the  modified  function 

--  project_op. 

indexarray  =>  indexes  :  seq  of  index; 


_****************************************************************************** 


index  =>  i :  integer; 
for  indexarray.indexes  use  linked; 


****************************************************************************** 

end 

****************************************************************************** 

process  relationalp  is 

relational  ::=  relationala raccess; 
end 


APPENDIX  F:  MODIFIED  PROJECT 


************************************************************** 


Projectjparseaction 


******************************************************************************** 

static  void  Pro ject_parse_action (query ) 
char*  query; 

{ 

char  *Rl_ptr, *char_ptr, *R2_ptr; 

integer  size, i; 

boolean  done  =  false, delimeterl  =  false; 

char_ptr   =   query; 

/*  allocate  room  for  parse  of  the  project  op  parameters 

Rl  will  hold  the  relation  being  operated  on, 

Attr_list  the  list  of  attr  to  be  projected,  and 

R2  the  resultant  relation   */ 
size  =  st rl en (query ) ; 

Rl  =  (char* ) calloc ( (size+1) , sizeof (char) ) ;  /*  Rl  is  global  */ 
Attr_list  =  (char* ) calloc ( (size+1 ), sizeof (char) ) ; 

/*  set  pointers  to  move  along  Rl  and  R2  as  characters  are  copied  in  one 

at  a  time.  */ 
Rl_ptr  =  Rl; 

/*  do  the  parse  */ 
char_ptr  =  query; 

/*  note:  if  size  gets  decremented  all  the  way  to  zero,  then  there  is  a 
problem  with  the  query  because  the  delimeter  '  =  '  or  '  project  ' 
could  not  be  found  */ 
while  (!done  &&  size  >  0) 
{ 

if  (*char_ptr  !=  '  ')  /*  if  not  a  space  copy  the  char  into  Rl  */ 
{ 

*Rl_ptr=*char_ptr ; /*parameter  relation* / 
++char_ptr; 
++Rl_ptr; 
--size; 
} 
else  /*  we  may  have  hit  a  delimeter  */ 
{ 

/*  check  to  see  if  next  char  is  a  "  p  "  -  which  is 
part  of  the  delimeter  "  project  "between  the  last 
two  parameters  */ 

if  (strncmp (char_ptr, "  project  " ,9)    =-    0) 
/*  then  it  is  project  */ 
{ 

for  (i  =0;  i  <  9;++i)  /*  jump  past  the  delimeter  */ 
{ 

++char_ptr; 
--size; 
} 
strcpy (Attr_list, char_ptr) ; 
/*  copy  list  of  attributes  into  Attr_list  and  now  parse  the 

list  of  attributes  */ 
done=true; 


189 


else  /*  the  space  is  part  of  the  first  parameter,  so  put  in  Rl  */ 
{ 

/*  space  is  part  of  first  relation  name  so  keep  it  */ 

*Rl_ptr=*char_ptr; 

++char_ptr; 

++Rl_ptr; 

--size; 
} 


} 


if  (size  !=  0)  /*  size  only  =  0  if  union  was  not  found  in  the  query  */ 

NULL; 
else 

idl_raise ( IDL_ERROR, "There    is   an   error    in  your   query!    Try   Again."); 
} 
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******************************************************************************** 


report_project_error 


******************************  - 


************************************* 


void  report_project_error ( f oundl , f ound2 , attr_found) 
boolean  f oundl,  f ound2 ,  attr_found; 

{ 

if  (! f oundl  &&  !found2) 
{ 

idl_raise ( IDL_ERROR, 

"Neither  of  the  two  relations  are  in  this  database!"); 
} 
else 


if  (  ! attr_f ound) 

idl_raise(IDL_ERROR, 

"All  of  the  attributes  in  the  attribute  list  \nare  not  in  Rl!"); 


if 


if 


if 


( ! f oundl) 

idl_raise(IDL_ERROR, 

"Rl  is  not  in  this  database!"); 

(  ! found2) 

idl_raise (IDL_ERROR, 

"R2  is  not  in  this  database!"); 


[f oundl  &&  found2) 

idl_raise (IDL_ERROR, 

"A  SERIOUS  ERROR  HAS  OCCURED  !!!!!!  Regroup.  Try  Again. 
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******************************************************************************** 


projectop 

******************************************************************************** 

idl_routine  void  project_op (relation) 
relational_relation   relation; 

{ 

relational_relation  ptr_Rl , ptr_Attr_list, ptr_result_rel , temp_relation; 

relational_database  database; 

relational_index_array  array_index;  /*beta  project*/ 

relational_index  attr_index;  /*beta  project*/ 

idl_trans_mode  tmode; 

idl_univ  root; 

string  parameterl , attr_string;   /*  references  to  the  parameter 

Rl,and  attr  list 
relations   respectively  */ 

idl_transaction  tr; 

boolean  f oundl , f ound2 , done, attr_f ound; 

boolean  is_writable  =  false, duplicate  =  true; 

char  *attr_ptr, *delimeter  =  ",";  /*  delimeter  between  elements 

in  attribute  list  */ 

string  *attr_list [100 ]  ; 

integer  i=l , count, size, index, index_array [100] , ii=0; 

/*  index  array  of  size  100  allows  a  relation  to  have  100  attributes  */ 

idl_linked_elem ( relational_tuple)  result_tuple; 

tr  =  idl_get_trans ( relation) ; 

tmode  =  i dl_trans_mode_de fault, • 

root  =  idl_trans_get_root ( tr)  ; 

database  =  idl_to (relational_database, root ) ; 

foundl  =  false; 

found2  =  true;/*  not  needed  for  beta  version,  thus  changed  to  true*/ 

done  =  false; 

is_writable  =  (idl_trans_write_count ( tr)  >  0); 

array_index  =  idl_new ( tr, relational_index_array ) ; /*creates  the  index  array 

to  be  used  in  the  beta 
version  of  this  op*/ 

array _index->indexes  =  idl_empty_l inked ( tr, relational_index) ; 

brw_input ("Project   Query", 

"Please    input    the    Project   query    (Rl   project   Attr_list):    ", 

0L,0L,0L, false, 

Pro ject_parse_action) ; 

/*  copy  the  C  strings  Rl,  R2  and  Attr_list  into  IDL  strings  */ 
parameterl  =  idl_copy_string ( tr , Rl ) ;  /*relation  being  operated  on*/ 
attr_string  =  idl_copy_string ( tr, Attr_list ) ; 

/*  parse  tokens  in  attribute  string  */ 

if  ( (attr_ptr  =  strtok (attr_string, delimeter) )  ==  NULL) 
( 

/*  error,  no  token  */ 

idl_raise (IDL_ERROR, 

"You  did  not  list  any  attribute/field  names  in\nyour  project  query! 
Try  again,  meathead!"); 
} 
else 
{ 

attr_list[0]  =  idl_new_string (tr, 80 ) ; 
attr_list[0]  =  idl_copy_string ( tr, attr_ptr) ; 
} 
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while  ( (attr_ptr  =  strtok (NULL, delimeter) )  !=  NULL) 

{ 

attr_list[i]  =  idl_new_string (tr, 80) ; 

attr_list[i]  =  idl_copy_string( tr,attr_ptr) ; 

i  +  +; 
} 

/*  search  the  database  for  the  relation  Rl  */ 
idl_linked_for  (relational_relation,database->relations, rel ) 
{ 

if  (strcmp  (rel->relation_name, parameterl )  ==  0) 
/*  found  relation  1  */ 
{ 

ptr_Rl  =  rel;  /*  point  at  relation  1  */ 
foundl  =  true; 
} 
}  idl_end_for 

count  =  i;  /*  count  is  the  number  of  tokens  -  1  */ 

/*  check  each  attr  name  in  the  attr  list  of  the  project  operation  to 
ensure  that  the  field  exists  in  the  relation  Rl  */ 

for (i=0; i<count ; ++i ) 
{ 

attr_found  =  false; 
ii=0; 

idl_array_f or (relational_name, ptr_Rl->attribute_names, aname) 
{ 

ii++;  /*  position  in  attribute  list  */ 

if  (strcmp  (aname->name, attr_list [i ] )  ==  0)  /*  attr  name  in  attr 

list  is  a  field 
of  Rl  */ 
{ 

attr_found  =  true; 

attr_index  =  idl_new( tr , relational_index) ; 

attr_index->i  =  ii; 

idl_insert_back ( relational_index, 

array_index->indexes, attr_index) ; 
break; 
) 
}  idl_end_for 

if  (  !attr_found) 
( 

break;  /*  an  attr  in  the  project  attr  list  is  not 
in  the  relation  Rl .  Thus,  the  operation 
cannot  be  performed  */ 
} 
} 

if  (foundl  &Sc   attr_found) 
{ 

/*  everything  is  ok,  perform  projection  operation  on  relation  Rl . 
Note,  in  this  implementation,  the  resultant  relation  doesn't 
already  exists  in  the  database.  */ 

ptr_result_rel  =  init_proj_result_rel (ptr_Rl , array_index) ; 

ptr_result_rel=idl_vop (ptr_Rl->tuple_type, relational_tuple, insert_f ields_b, 

(ptr_Rl, ptr_result_rel , array _index) ) ; 

idl_insert_back ( relational_relation, da t abase- >rel at  ions ,ptr_result_rel ) ; 
} 
else 
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report_project_error ( f oundl , f ound2 , attr_f ound) ; 
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******************************************************************************** 

insertfieldsb 

******************************************************************************** 

idl_routine  relational_relation  insert_f ields_b ( rel , result_rel , index_array) 

relational_relation  rel,  result_rel; 

relational_index_array  index_array ; 
{ 

return  result_rel; 
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******************************************************************************** 


in  sertem  pfieldsb 


******************************************************************************** 

idl_routine  relational_relation  insert_emp_f ields_b (rel , result_rel, index_array) 
relational_relation  rel,  result_rel; 
relational_index_array  index_array ; 
{ 

idl_transaction  tr  =  idl_get_trans (rel) ; 
relational_result_tuple  new_tuple ; 

resul t_rel->tuples  =  idl_empty_l inked ( tr, relational_tuple) ; 

idl_linked_for  (relational_tuple, rel->tuples, rel_tuple) 
{ 

/*  iterate  through  each  tuple  and  for  each  tuple  iterate  through 

the  index_array  and  use  a  case  statement  to  reference  objects  for 
fields  to  be  entered  into  the  result  relation  */ 

new_tuple  =  idl_new (tr, relational_result_tuple) ; 
new_tuple->values  =  idl_empty_l inked ( tr , relational_any ) ; 

idl_linked_f or  (relational_index, index_array->indexes , index) 
{ 

switch  (index->i) 
{ 

case  1: 
idl_insert_back (relational_any , new_tuple->values, rel_tuple->person) ; 

break; 
case  2: 
idl_insert_back (relational_any, new_tuple->values, rel_tuple->address) ; 
break; 
case  3 : 
idl_insert_back (relational_any , new_tuple->values, rel_tuple->phone) ; 
break; 
case  4 : 

/*  widget  */ 
break; 
default: 

idl_raise(IDL_ERROR, 

"There  is  a  problem  in  the  employee  insert  field  beta 
function! " ) ; 

break; 
) 
}  idl_end_for 

idl_insert_back (relational_tuple, result_rel->tuples,  new_tuple)  ; 

}  idl_end_for 

return  result_rel; 
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******************************************************************************** 

init_proj_resu  Itrel 

******************************************************************************** 

relational_relation  init_proj_result_rel (ptr_Rl , index_array ) 
relational_relation  ptr_Rl; 
relational_index_array  index_array ; 
{ 

relational_relation  resul t_relation; 

static  integer  resul t_rel_num  =  0; 

idl_transaction  tr; 

string  empty, result_rel_name; 

char  resul t_name [80 ] ; 

integer  degree  =  0 ,  i ; 

tr  =  idl_get_trans (ptr_Rl ) ; 

i  =  0; 

idl_linked_for  (relational_index, index_array->indexes , index) 

{ 

i  +  +  ; 

} idl_end_f or 

degree  -    i ; 

result_relation  =  idl_new (tr, relational_relation) ;  /*  must  still  assign 

legal  values  */ 

/*  set  up  a  unique  name  for  resultant  relation  */ 
sprintf (result_name,"%ldRESULT_%c%c", 

++ resul t_rel_num, 

ptr_Rl->relation_name [0 ] , 

ptr_Rl->relation_name [ 1 ] ) ; 
resul t_rel_name  =  idl_copy_string ( tr, result_name) ; 

result_relation->relation_name  =  result_rel_name; 

result_relation->attribute_names  =  idl_new_array ( tr, relational_name, degree) ; 
result_relation->attribute_types  =  idl_new_array ( tr, relational_name, degree) ; 

/*  assign  default  values  for  attribute  names  to  be  the  same  as  those  in 

Rl  relation  */ 
i=0; 

idl_linked_f or  ( relational_index, index_array->indexes , index) 
{ 

result_relation->attribute_names [ i ] =ptr_Rl->attribute_names [ ( index->i ) -1 ] ; 
result_relation->attribute_types [ i ] =ptr_Rl->attribute_types [ ( index->i ) -1 ] ; 
i  +  + ; 
} idl_end_for 

resul t_relation->tuples  =  idl_empty_l inked ( tr , relational_tuple)  ; 

/*  assign  a  default  tuple  type  that  is  the  same  as  the  first  relations  */ 
result_relation->tuple_type  =  idl_to ( relational_tuple, 

idl_new( tr, relational_result_tuple) ) ; 

/*  default  key  is  the  key  of  relation  Rl  */ 
result_relation->key  =  ptr_Rl->key ; 

return  result_relation; 
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APPENDIX  G:  MODIFIED  CARTESIAN  PRODUCT 


******************************************************************************** 


Cartesianjparseaction 


******************************************************************************** 

static  void  Cartesian_parse_action (query) 
char*  query; 

{ 

char  *Rl_ptr, *char_ptr; 

integer  size, i ; 

boolean  done  =  false, delimeterl  =  false; 

char_ptr  =  query; 

/*  allocate  room  for  parse  of  the  Cartesian  product  op  parameters 

Rl  will  hold  the  first  parameter  and  R2  the  second  */ 
size  =  strlen (query ) ; 

Rl  =  (char* ) calloc ( (size+1 ), sizeof (char) ) ? 
R2  =  (char* ) calloc ( (size+1) , sizeof (char)  )  ; 

/*  set  pointer  to  move  along  Rl  as  characters  are  copied  in  one 

at  a  time.  */ 
Rl_ptr  =  Rl; 

/*  do  the  parse  */ 
char_ptr  =  query; 

/*  note:  if  size  gets  decremented  all  the  way  to  zero,  then  there  is  a 
problem  with  the  query  because  the  delimeter  '  X  '  could  not  be 
found  */ 
while  (!done  &&  size  >  0) 
{ 

if  (*char_ptr  !=  '  ')  /*  if  not  a  space  copy  the  char  into  R3  */ 
{ 

*Rl_ptr=*char_ptr; 
++char_ptr; 
++Rl_ptr; 
--size; 
} 
else  /*  we  may  have  hit  the  a  delimeter  */ 
( 

/*  check  to  see  if  next  char  is  a  "  X  "  -  which  separates  the 
two  operands  of  the  operation  */ 

if  (strncmp(char_ptr, "  X  ",3)  ==  0)  /*  then  it  is  X  sentinal  */ 
{ 

for  (i  =0;  i  <  3;++i)  /*  jump  past  the  delimeter  */ 
( 

++char_ptr; 
--size; 
) 
strcpy (R2 ,char_ptr) ;  /*  copy  second  parameter  into  R2  */ 
done=true; 
} 
else  /*  the  space  is  part  of  the  first  parameter,  so  put  in  Rl  */ 
{ 

/*  space  is  part  of  first  relation  name  so  keep  it  */ 

*Rl_ptr=*char_ptr; 

++char_ptr; 
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++Rl_ptr; 
--size; 
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******************************************************** 


report_Cart_product_error 


*********************************************************************: 


void  report_Cart_product_error ( f oundl , f ound2 , f ound3 ) 
boolean  f oundl , £ound2, found3 ; 

{ 

if  (! f oundl  &&  !found2) 


{ 


idl_raise(IDL_ERROR, 

"Neither  of  the  two  relations  are  in  this  database!"); 


else 

{ 


if  (Ifoundl) 

idl_raise (IDL_ERROR, 

"Rl  is  not  in  this  database!"); 

( ! found2) 

idl_rai  se ( IDL_ERROR , 

"R2  is  not  in  this  database!"); 

( ! f ound3 ) 

idl_raise (IDL_ERROR, 

"R3  is  not  in  this  database!"),- 

if  (f oundl  &&  found2  &&  found3) 

idl_raise(IDL_ERROR, 

"A  SERIOUS  ERROR  HAS  OCCURED  !!!!!!  Regroup.  Try  Again."); 


200 


******************************************************************************** 

cartjprodop 

******************************************************************************** 

idl_routine  void  cart_prod_op (relation) 
relational_relation  relation; 

{ 

relational_relation  ptr_Rl, ptr_R2 , resutl_rel, temp_relation; 

relational_database  database; 

idl_trans_mode  tmode; 

idl_univ  root; 

string  parameterl ,parameter2 , result_rel ;   /*  references  to  the  parameters 

Rl ,  R2  and  R3  respectively  */ 
idl_transaction  tr; 
boolean  f oundl , f ound2 , f ound3 ; 
boolean  is_writable  =  false, duplicate  =  true; 

tr  =  idl_get_trans ( relation) ; 

tmode  =  idl_trans_mode_default ; 

root  =  idl_trans_get_root ( tr) ; 

database  =  idl_to (relational_database, root ) ; 

foundl  =  false; 

found2  =  false; 

found3  =  true;  /*  beta  version  doesn't  use  a  predefined  result  rel  */ 

is_writable  =  ( idl_trans_write_count ( tr)  >  0); 

brw_input ( "Cartesion  Product  Query", 

"Please  input  the  Cartesian  product  query  (Rl  X  R2) :  ", 
0L,0L,0L, false, 
Cartesian_parse_action) ; 

/*  copy  the  C  strings  Rl  and  R2  into  IDL  strings  */ 
parameterl  =  idl_copy_string ( tr,Rl ) ; 
parameter2  =  idl_copy_string ( tr, R2 ) ; 

/*  don't  do  anything  if  the  resultant  relation  is  one  of  the  two  operands. 
However,  the  resultant  relation  can  be  one  that  exists  in  the  data. 
In  this  case,  the  specified  resultant  relation  will  be  over  written.  */ 

/*  search  the  database  for  the  two  relations:  Rl,  and  R2  */ 
idl_linked_f or  (relational_relation, dat abase- >rel at ions , rel ) 
{ 

if  (strcmp  (rel->relation_name, parameterl )  ==  0) 
/*  found  relation  1  */ 
{ 

ptr_Rl  =  rel;  /*  point  at  relation  1  */ 
foundl  =  true; 
} 

if  (strcmp  ( rel->relation_name, parameter2 )  ==  0) 
/*  found  relation  2  */ 
{ 

ptr_R2  =  rel; 
found2  =  true; 
} 

}  idl_end_for 

if  (foundl  &&  found2) 
{ 

/*  perform  concatenation  of  tuples  for  Cartesian  product. 

Note,  in  this  implementation,  the  resultant  relation  does  not 
already  exists  in  the  database.  */ 


result_rel  =  init_Cart_result_rel (ptr_Rl , ptr_R2 ) ; 
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result_rel=idl_vop (result_rel->tuple_type, relational_tuple, insert_tuples_b, 

(ptr_Rl,ptr_R2,result_rel) ) ; 

idl_insert_bac)c  ( relat ional_relat ion, database- >relat ions, result_rel) ; 
} 
else 
{ 

report_CarC_product_error (foundl , found2 , f ound3 ) ; 

} 
} 
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******************************************************************************** 

initCartresultrel 

******************************************************************************** 

relational_relation  ini t_Cart_resul t_rel (ptr_Rl , ptr_R2) 
relational_relation  ptr_Rl , ptr_R2 ; 

{ 

relational_relation  resul t_relat ion; 

static  integer  result_rel_num  =  0; 

idl_transaction  tr; 

string  result_rel_name; 

char  resul t_name [ 80 ]  ; 

integer  degreel  =  0,degree2  =  0 , resul t_degree, i ; 

tr  =  idl_get_trans (ptr_Rl ) ; 

degreel  =  idl_array_size (ptr_Rl->attribute_names) ; 
degree2  =  idl_array_size (ptr_R2->attribute_names) ; 
resul t_degree  =  degreel  +  degree2; 

result_relation  =  idl_new ( tr, relational_relat i on) ;  /*  must  still  assign 

legal  values  */ 

/*  set  up  a  unique  name  for  resultant  relation  */ 
sprintf (result_name, "%ldRESULT_%c%c . %c%c" , 

++ resul t_rel_num, 

ptr_Rl->relation_name [0 ] , 

ptr_Rl->relation_name [1 ] , 

ptr_R2->relation_name [0 ] , 

ptr_R2->relation_name [1] ) ; 
resul t_rel_name  =  idl_copy_string ( tr, result_name) ; 

result_relation->relation_name  =  result_rel_name; 
result_relation->attribute_names  =  idl_new_array ( tr, relational_name, 

resul t_degree) ; 
resul t_relation->attribute_types  =  idl_new_array ( tr , relational_name, 

resul t_degree) ; 

/*  assign  default  values  for  attribute  names  to  be  the  same  as  those  in 
Rl  and  R2   */ 

for  (  i=0;  i<degreel;  ++i) 
{ 

resul t_relation->attribute_names [i]  =  ptr_Rl->attribute_names [i] ; 

resul t_re la tion->attr ibute_types [ i ]  =  ptr_Rl->attribute_types [i ] ; 
} 

for  (  i=0;  i<degree2;  ++i) 
{ 

result_relation->attribute_names [degreel+i ]  =  ptr_R2->attribute_names [ i ] ; 

resul t_relation->attribute_types [degreel+i]  =  ptr_R2->attribute_types [i ] ; 
} 

result_relation->tuples  =  idl_empty_l inked ( tr, relational_tuple) ; 

/*  assign  a  default  tuple  type  result  tuple  */ 
result_relation->tuple_type  =  idl_to (relational_tuple, 

idl_new( tr, relational_result_tuple) ) ; 

/*  default  key  is  the  key  of  relation  Rl  */ 
result_relation->key  =  ptr_Rl->key ; 

return  result_relation; 
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******************************************************************************** 

inserttuplesb 

******************************************************************************** 

static  relational_relation  insert_tuples_b ( rl , r2 , result_rel ) 
relational_relation  rl , r2 , result_rel ; 

{ 

relational_result_tuple  new_tuple; 
relational_tuple  rell,rel2; 
idl_transaction  tr  =  idl_get_trans ( rl ) ; 

/*  get  rid  of  any  tuples  that  may  be  in  the  resultant  relation  structure 
prior  to  insert  the  new  result  */ 

result_rel->tuples  =  idl_empty_linked ( tr , relational_tuple) ; 

idl_linked_for  (relational_tuple, rl->tuples, rl_tuple) 
{ 

idl_linked_f or  ( relational_tuple, r2-> tuples , r2_tuple) 
{ 

/*  send  message  to  get  a  new  tuple  created  with  valid  default 
values.  */ 

new_tuple  =  idl_new ( tr, relational_result_tuple) ; 
new_tuple->values  =  idl_empty_l inked ( tr, relational_any) ; 

idl_insert_back (relational_any , new_tuple->values, rl_tuple) ; 
idl_insert_back (relational_any, new_tuple->values, r2_tuple) ; 

idl_insert_back (relational_tuple, re su 1 t_r el -> tuples, new_tuple) ; 

}  idl_end_for 
}  idl_end_for 

return  result_rel; 
} 
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